Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.php > #16438 > unrolled thread

PHP processing steps to apply to a URL to make it safe

Back to article view | Back to comp.lang.php

Contents

  PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-17 09:37 +0000
    Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 11:05 +0100
      Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-17 15:04 +0000
        Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 10:54 -0500
          Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 01:09 +0000
            Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 21:12 -0500
              Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 19:07 +0000
                Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-20 21:07 +0100
                  Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 20:35 +0000
                    Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-20 21:40 +0100
                      Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 21:02 +0000
                Re: PHP processing steps to apply to a URL to make it safe gordonb.lkcah@burditt.org (Gordon Burditt) - 2016-02-29 21:29 -0600
        Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-17 23:33 +0100
          Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 01:12 +0000
            Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-18 21:48 +0100
          Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 08:05 +0100
            Re: PHP processing steps to apply to a URL to make it safe Tim Streater <timstreater@greenbee.net> - 2016-02-18 09:59 +0000
              Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 10:29 +0000
                Re: PHP processing steps to apply to a URL to make it safe Tim Streater <timstreater@greenbee.net> - 2016-02-18 11:36 +0000
              Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 15:44 +0100
            Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-18 21:47 +0100
        Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 08:02 +0100
          Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 19:29 +0000
            Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-20 21:37 +0100
              Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 21:37 +0000
                Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-21 15:02 +0100
                  Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 15:02 +0000
    Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 08:19 -0500
      Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 14:43 +0100
        Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 15:04 +0100
          Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 15:17 +0100
            Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 15:47 +0100
              Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 15:57 +0100
                Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 10:57 -0500
                  Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 17:10 +0100
                    Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 12:11 -0500
                      Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 18:51 +0100
                        Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 12:55 -0500
                Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 19:06 +0100
                  Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 20:19 +0100
                    Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 08:18 +0100
                      Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-18 09:20 +0100
                        Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 15:48 +0100
                          Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-18 16:25 +0100
                            Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-18 17:00 +0100
                              Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-18 22:26 +0100
                          Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-18 10:48 -0500
              Re: PHP processing steps to apply to a URL to make it safe "Christoph M. Becker" <cmbecker69@arcor.de> - 2016-02-17 16:38 +0100
                Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 10:56 -0500
                Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 19:08 +0100
                Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-17 23:35 +0100
            Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 09:56 -0500
              Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 16:44 +0100
                Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 12:12 -0500
                  Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 19:04 +0100
        Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 09:55 -0500
          Re: PHP processing steps to apply to a URL to make it safe "R.Wieser" <address@not.available> - 2016-02-17 16:39 +0100
            Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 11:00 -0500
      Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-17 15:15 +0000
        Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-17 11:05 -0500
          Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 01:18 +0000
        Re: PHP processing steps to apply to a URL to make it safe Arno Welzel <usenet@arnowelzel.de> - 2016-02-17 19:14 +0100
          Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 00:19 +0000
        Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-17 23:36 +0100
    Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-17 23:26 +0100
      Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-18 00:36 +0000
        Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-18 22:03 +0100
          Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 19:38 +0000
            Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-20 21:17 +0100
              Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-20 20:56 +0000
                Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-20 23:48 +0100
                  Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 09:37 +0000
                    Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-21 14:42 +0100
                      Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 15:03 +0000
                        Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-21 14:09 -0500
                          Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 19:34 +0000
                            Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-21 14:49 -0500
                              Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 19:56 +0000
                                Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-21 20:29 -0500
                                  Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-22 07:30 +0000
                                    Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-22 08:13 -0500
                                      Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-22 15:01 +0000
                                        Re: PHP processing steps to apply to a URL to make it safe Jerry Stuckle <jstucklex@attglobal.net> - 2016-02-22 10:31 -0500
                            Re: PHP processing steps to apply to a URL to make it safe Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-02-22 00:10 +0100
                              Re: PHP processing steps to apply to a URL to make it safe James Harris <james.harris.1@gmail.com> - 2016-02-21 23:45 +0000
    Re: PHP processing steps to apply to a URL to make it safe pittendrigh <Sandy.Pittendrigh@gmail.com> - 2016-03-22 05:23 -0700

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#16491

R.Wieser schrieb am 2016-02-17 um 20:19:

> Arno,
> 
>> My point is, that an URL itself is just an URL
> 
> No, it isn't.   Its rather easy to combine the addres itself with some data
> into an URL, just as any run-of-the-mill HTTP can GET do.    You do not even
> need to know how to program or write HTML, you can do that in the adres bar
> of any browser.

And? It is then still just an URL.

>> and your reference to SQL injection in this context doesn't
>> make any sense at all.
> 
> Are you sure ?

Yes. Because without a database connection there is no "SQL injection"
at all.

> From the OP's first post:
> 
> [quote]
> All needed? Any not needed? Latest firefox strips out any .. entries
> before sending the URL but I am not sure that all earlier browsers would.
> [/quote]
> 
> AFAICS that means he will be receiving URLs from untrusted sources ...

And? I still don't see "database" which is in any case required to
produce a thing like "SQL injection".

And even if a database is involved - sanitizing values or using prepared
statements to avoid SQL injections is *alway* neccessary and not only
for values which are build based on URLs.

>> BTW: at least you should think about your way to quote posts.
> 
> Why ?  Whats *WRONG* with it.   And no, I do not consider anyones
> *preference* in this matter to be more important than mine.  Explain
> yourself and I will consider the arguments.  Thats all I can promise.

The fact that you leave nearly everything of the quoted post in place
even if you don't refer to the quoted text. It's also not useful to
quote the *whole* posting below your reply again since people read from
top to bottom and it's really confusing reading a reply first and then
the text to which the reply refers to. This is a bad habit coming from
e-mail clients using this "original message:" below the reply.

In addition: Signatures are never being quoted - that's why signatures
start with "-- " (look carefully and you will notice the space after the
"--"). This is the indication for properly working newsreaders where to
stop quoting at all.

> By the way: I quite dislike top, smack-in-the-middle and bottom posting
> alike, only to be topped by the ones where absolutily nothing is quoted (not
> even the name of the person who the response is directed towards).

That's why there a references and every newsreader is able to show you
which posts a reply refers to and show a threaded message list as well.

[...]
> So yes, I've been thinking about how I quote posts.

Thanks.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#16493

Arno,

> And? It is then still just an URL.

And flawed code is then still just code.

... as long as you do not use it in any way nothing will go wrong there too.

Also, this is the third time you put that forward.  I'm not willing to
participate in that merry-go-round.  You can stay on if you like though.
Enjoy yourself.

> And? I still don't see "database" which is in any case
> required to produce a thing like "SQL injection".

Arno, you're behaving like an idiot.  You have, as you said yourself, no
clue to what the OP is up to, but at the same time you are *very* sure (at
least to me) that it definitily can't be anything related to SQL injection.
That simply does not compute.

> That's why there a references and every newsreader is
> able to show you which posts a reply refers to and show
> a threaded message list as well.

Yeah, that really works well with one of those bloody Google-groups posters
of that last (no quote, not even a name) group, and where the replied-to
post has long been removed (as in years ago) from the real newsgroup
servers.

Think a bit further than your own immediate needs / setup /environment
please. :-\

Regards,
Rudy Wieser


-- Origional message:
Arno Welzel <usenet@arnowelzel.de> schreef in berichtnieuws
56C5702C.9010303@arnowelzel.de...
> R.Wieser schrieb am 2016-02-17 um 20:19:
>
> > Arno,
> >
> >> My point is, that an URL itself is just an URL
> >
> > No, it isn't.   Its rather easy to combine the addres itself with some
data
> > into an URL, just as any run-of-the-mill HTTP can GET do.    You do not
even
> > need to know how to program or write HTML, you can do that in the adres
bar
> > of any browser.
>
> And? It is then still just an URL.
>
> >> and your reference to SQL injection in this context doesn't
> >> make any sense at all.
> >
> > Are you sure ?
>
> Yes. Because without a database connection there is no "SQL injection"
> at all.
>
> > From the OP's first post:
> >
> > [quote]
> > All needed? Any not needed? Latest firefox strips out any .. entries
> > before sending the URL but I am not sure that all earlier browsers
would.
> > [/quote]
> >
> > AFAICS that means he will be receiving URLs from untrusted sources ...
>
> And? I still don't see "database" which is in any case required to
> produce a thing like "SQL injection".
>
> And even if a database is involved - sanitizing values or using prepared
> statements to avoid SQL injections is *alway* neccessary and not only
> for values which are build based on URLs.
>
> >> BTW: at least you should think about your way to quote posts.
> >
> > Why ?  Whats *WRONG* with it.   And no, I do not consider anyones
> > *preference* in this matter to be more important than mine.  Explain
> > yourself and I will consider the arguments.  Thats all I can promise.
>
> The fact that you leave nearly everything of the quoted post in place
> even if you don't refer to the quoted text. It's also not useful to
> quote the *whole* posting below your reply again since people read from
> top to bottom and it's really confusing reading a reply first and then
> the text to which the reply refers to. This is a bad habit coming from
> e-mail clients using this "original message:" below the reply.
>
> In addition: Signatures are never being quoted - that's why signatures
> start with "-- " (look carefully and you will notice the space after the
> "--"). This is the indication for properly working newsreaders where to
> stop quoting at all.
>
> > By the way: I quite dislike top, smack-in-the-middle and bottom posting
> > alike, only to be topped by the ones where absolutily nothing is quoted
(not
> > even the name of the person who the response is directed towards).
>
> That's why there a references and every newsreader is able to show you
> which posts a reply refers to and show a threaded message list as well.
>
> [...]
> > So yes, I've been thinking about how I quote posts.
>
> Thanks.
>
>
>
> --
> Arno Welzel
> http://arnowelzel.de
> http://de-rec-fahrrad.de
> http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#16499

R.Wieser schrieb am 2016-02-18 um 09:20:

> Arno,
[...]
>> And? I still don't see "database" which is in any case
>> required to produce a thing like "SQL injection".
> 
> Arno, you're behaving like an idiot.  You have, as you said yourself, no
> clue to what the OP is up to, but at the same time you are *very* sure (at
> least to me) that it definitily can't be anything related to SQL injection.
> That simply does not compute.

I  give up - you don't get it.

[Quote style]
> Think a bit further than your own immediate needs / setup /environment
> please. :-\

Your environment needs the FULL(!) old post including the signature to
be quoted below your reply completely? Why?

[Useless fullquote deleted]


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#16502

Arno,

> I  give up - you don't get it.

What *is* there to get for me ?

You've put that "its just an URL" stance forward three times, not trying to
explain anything about it, and not responding to my counter-example to it.
You give me *zero* chance to understand your position.

And as you are not responding to my counter-example, should I just assume
you have not got the slightest idea either ?    I mean, if you do you would
be able to counter my counter example (which you don't) ...    Pot, meet
kettle ?

> Your environment needs the FULL(!) old post including the
> signature to be quoted below your reply completely? Why?

I already explained that.  Can't you even *read* ?   Or do you simply refuse
to acknowledge anything that does not conform to your own ideas of how stuff
ought to work ?

And by the way, you also did not explain in any way how you on one hand do
not know what the OP is busy with, but on the other hand know for certain
what it definitily isn't.   Yes, that did not pass me by unnoticed.   The
absense of any reaction from you to it does tell me enough though.

Goodbye.

Regards,
Rudy Wieser


-- Origional message:
Arno Welzel <usenet@arnowelzel.de> schreef in berichtnieuws
56C5D9D4.2020503@arnowelzel.de...
> R.Wieser schrieb am 2016-02-18 um 09:20:
>
> > Arno,
> [...]
> >> And? I still don't see "database" which is in any case
> >> required to produce a thing like "SQL injection".
> >
> > Arno, you're behaving like an idiot.  You have, as you said yourself, no
> > clue to what the OP is up to, but at the same time you are *very* sure
(at
> > least to me) that it definitily can't be anything related to SQL
injection.
> > That simply does not compute.
>
> I  give up - you don't get it.
>
> [Quote style]
> > Think a bit further than your own immediate needs / setup /environment
> > please. :-\
>
> Your environment needs the FULL(!) old post including the signature to
> be quoted below your reply completely? Why?
>
> [Useless fullquote deleted]
>
>
> --
> Arno Welzel
> http://arnowelzel.de
> http://de-rec-fahrrad.de
> http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#16505

R.Wieser schrieb am 2016-02-18 um 16:25:

> Arno,
[...]
>> Your environment needs the FULL(!) old post including the
>> signature to be quoted below your reply completely? Why?
> 
> I already explained that.  Can't you even *read* ?   Or do you simply refuse
> to acknowledge anything that does not conform to your own ideas of how stuff
> ought to work ?

It's not *my* idea how to quote in usenet postings!

Further reading:

<https://www.netmeister.org/news/learn2quote.html>
<http://tools.ietf.org/html/rfc1849#section-4.3.2>
<http://tools.ietf.org/html/rfc3676>

> And by the way, you also did not explain in any way how you on one hand do
> not know what the OP is busy with, but on the other hand know for certain
> what it definitily isn't.   Yes, that did not pass me by unnoticed.   The
> absense of any reaction from you to it does tell me enough though.

Well - I assumed only what is known. And at the time the OP asked he
asked for "processing an URL to make it safe" and he did NOT mention
"creating SQL queries based on anything passed with the URL".

Why you think of "SQL injection" if someone talks about how to process
URLs is your own problem.



-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#16514

Arno Welzel wrote:

> R.Wieser schrieb am 2016-02-18 um 16:25:
>> Arno,
> [...]
>>> Your environment needs the FULL(!) old post including the
>>> signature to be quoted below your reply completely? Why?
>> I already explained that.  Can't you even *read* ?   Or do you simply
>> refuse to acknowledge anything that does not conform to your own ideas of
>> how stuff ought to work ?
> 
> It's not *my* idea how to quote in usenet postings!
> […]

Wasted effort.  It’s an anti-social pseudo-anonymous address munger posting 
via a provider whose terms of use imply in Article 5, § 3 that address 
munging is not allowed.  Because of that, I would not have seen those 
postings had you not quoted them.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16504

On 2/18/2016 9:48 AM, Arno Welzel wrote:
> R.Wieser schrieb am 2016-02-18 um 09:20:
> 
>> Arno,
> [...]
>>> And? I still don't see "database" which is in any case
>>> required to produce a thing like "SQL injection".
>>
>> Arno, you're behaving like an idiot.  You have, as you said yourself, no
>> clue to what the OP is up to, but at the same time you are *very* sure (at
>> least to me) that it definitily can't be anything related to SQL injection.
>> That simply does not compute.
> 
> I  give up - you don't get it.
>

Arno,

You're arguing with an idiot.  He's been in similar arguments with
people more knowledgeable than he in other newsgroups, also.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16453

Arno Welzel wrote:

> How does an *URL* itself cause an SQL injection? At least a PHP script
> has to use the provided values and use it within an SQL statement.

Consider that *some* URL is supplied and expected as input *parameter*.
 Unless the parameter is validated or sanitized, there could be a
security issue.

-- 
Christoph M. Becker

[toc] | [prev] | [next] | [standalone]

#16457

On 2/17/2016 10:38 AM, Christoph M. Becker wrote:
> Arno Welzel wrote:
> 
>> How does an *URL* itself cause an SQL injection? At least a PHP script
>> has to use the provided values and use it within an SQL statement.
> 
> Consider that *some* URL is supplied and expected as input *parameter*.
>  Unless the parameter is validated or sanitized, there could be a
> security issue.
> 

But it would not cause SQL tables to disappear, unless it was used as
input to a SQL statement - in which case sanitization would be different.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16469

Christoph M. Becker schrieb am 2016-02-17 um 16:38:
> Arno Welzel wrote:
> 
>> How does an *URL* itself cause an SQL injection? At least a PHP script
>> has to use the provided values and use it within an SQL statement.
> 
> Consider that *some* URL is supplied and expected as input *parameter*.
>  Unless the parameter is validated or sanitized, there could be a
> security issue.

Sure - but the question of the OP was not "how can I validate/sanitize
input parameters" but "how can I make an URL safe" - and since an URL
itself is not "safe" or "unsafe" the OP has to explain what he wants to
achieve. Otherwise one can only recommend general guidelines how to
avoid security problems - but this has nothing to do with URLs itself at
all.


-- 
Arno Welzel
http://arnowelzel.de
http://de-rec-fahrrad.de
http://fahrradzukunft.de

[toc] | [prev] | [next] | [standalone]

#16478

Christoph M. Becker wrote:

> Arno Welzel wrote:
>> How does an *URL* itself cause an SQL injection? At least a PHP script
>> has to use the provided values and use it within an SQL statement.
> 
> Consider that *some* URL is supplied and expected as input *parameter*.
>  Unless the parameter is validated or sanitized, there could be a
> security issue.

Then you sanitize that particular parameter and escape it for output, using 
the built-in functions, respectively; you do not futilely attempt to make 
the request URI safe.

-- 
PointedEars
Zend Certified PHP Engineer 
<http://www.zend.com/en/yellow-pages/ZEND024953> | Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#16449

On 2/17/2016 9:17 AM, R.Wieser wrote:
> Arno,
> 
>> And what do SQL injections have to do with "safe URL"?
> 
> Please step away from the computer *now*.  Bring it back to where you bought
> it and ask your money back.
> 
> In other words: Either you are trolling, or you should not be doing anything
> with PHP.
> 
> Regards,
> Rudy Wieser
>

IOW, you have absolutely no idea what you're talking about.  I suggest
YOU get away from computers.  You are dangerous to the entire internet.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16455

Jerry,

> IOW, you have absolutely no idea what you're talking about.

Ofcourse not.  It was only by sheer luck that I happened to pick a link to a
small strip joking about the most common problem with non-sanitized input
....

Yeah, that must be it. Just luck.   Riiiight...

Regards,
Rudy Wieser


-- Origional message:
Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
na21gj$utt$2@jstuckle.eternal-september.org...
> On 2/17/2016 9:17 AM, R.Wieser wrote:
> > Arno,
> >
> >> And what do SQL injections have to do with "safe URL"?
> >
> > Please step away from the computer *now*.  Bring it back to where you
bought
> > it and ask your money back.
> >
> > In other words: Either you are trolling, or you should not be doing
anything
> > with PHP.
> >
> > Regards,
> > Rudy Wieser
> >
>
> IOW, you have absolutely no idea what you're talking about.  I suggest
> YOU get away from computers.  You are dangerous to the entire internet.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

[toc] | [prev] | [next] | [standalone]

#16464

On 2/17/2016 10:44 AM, R.Wieser wrote:
> Jerry,
> 
>> IOW, you have absolutely no idea what you're talking about.
> 
> Ofcourse not.  It was only by sheer luck that I happened to pick a link to a
> small strip joking about the most common problem with non-sanitized input
> ....
> 
> Yeah, that must be it. Just luck.   Riiiight...
> 
> Regards,
> Rudy Wieser
> 
>

And now you're trying to backpedal.  You don't even know what SQL
injection is - or that it's completely unrelated to the OP's question.

But then you're well known for trolling in multiple newsgroups.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16467

Jerry,

> And now you're trying to backpedal.

Ofcourse.  That must be it.

A suggestion though: look up "sarcasm" in the dictionary.  You might be in
for a surprise.

> You don't even know what SQL injection is -

How would you know #1

> or that it's completely unrelated to the OP's question.

How would you know #2

... And I've *still* not seen any hint to you trying to support your own
position, *nor* anything tearing mine down.

My guess ?   You do not *have* anything in that regard.   You just keep on
bluffing away, like a broken record.

This game has gone on long enough though.  Goodbye.

Regards,
Rudy Wieser


-- Origional message:
Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
na29g8$a65$2@jstuckle.eternal-september.org...
> On 2/17/2016 10:44 AM, R.Wieser wrote:
> > Jerry,
> >
> >> IOW, you have absolutely no idea what you're talking about.
> >
> > Ofcourse not.  It was only by sheer luck that I happened to pick a link
to a
> > small strip joking about the most common problem with non-sanitized
input
> > ....
> >
> > Yeah, that must be it. Just luck.   Riiiight...
> >
> > Regards,
> > Rudy Wieser
> >
> >
>
> And now you're trying to backpedal.  You don't even know what SQL
> injection is - or that it's completely unrelated to the OP's question.
>
> But then you're well known for trolling in multiple newsgroups.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

[toc] | [prev] | [next] | [standalone]

#16448

On 2/17/2016 8:43 AM, R.Wieser wrote:
> -- Origional message:
> Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
> na1rs4$9tp$1@jstuckle.eternal-september.org...
>> On 2/17/2016 4:37 AM, James Harris wrote:
>>> In line with the principle of a program vetting its input, this is about
>>> vetting the supplied URL.
>>>
>>> In order to process a URL or parts of a URL in PHP what processing ought
>>> to be applied to it? I have been using some steps which I will write
>>> below but I am becoming increasingly uncertain that I have covered all
>>> the bases.
>>>
>>> The main concern is safety - ensuring that the PHP code is protected
>>> against anything that might otherwise trip it up. The second concern is
>>> correctness in even corner cases such as odd browsers or extended
>>> character sets.
>>>
>>> I have been working with $_SERVER["REQUEST_URI"], in case that is
> relevant.
>>>
>>> Steps so far:
>>>
>>>   urldecode to convert %nn etc
>>>
>>>   trim "/" from the ends in order to normalise
>>>
>>>   check each character is from an allowed set
>>>
>>>   check there are no // parts
>>>
>>>   check there are no .. parts
>>>
>>> All needed? Any not needed? Latest firefox strips out any .. entries
>>> before sending the URL but I am not sure that all earlier browsers
> would.
>>>
>>> In addition to the above, could the URL be in Unicode form? I was
>>> thinking to change to index through it with
>>>
>>>   $uri[n]
>>>
>>> but I gather that will index bytes and not characters. Could the URL
>>> string that PHP receives be stored as Unicode and should something like
>>> mb_substr be used instead?
>>>
>>> That's all the steps I have come up with so far. It seems a lot.
>>> Presumably you guys have steps you use yourselves. Are all the things I
>>> have listed necessary? Is there anything else that should be done to
>>> process URLs (or components thereof) safely and correctly?
>>>
>>> James
>>>
>>
>> What are you trying to "make safe"?  A url is either good or bad.  If
>> it's bad, it won't bring up a site.  If it's good, it will bring up a
>> site, but that site may not be safe.
>>
>> What are you actually trying to accomplish here?  I'm not sure how a
>> supplied URL will affect your PHP code.
>>
> Jerry,
> 
>> What are you trying to "make safe"?  A url is either good or bad.
> 
> I've got a name for you: "Bobby Tables".  Google it. And XKCD has got a page
> about him: https://xkcd.com/327/
> 
> Regards,
> Rudy Wieser
>

Which has absolutely nothing to do with my question.

And don't top post.

> 



-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16454

Jerry,

> Which has absolutely nothing to do with my question.

Really ?  Than I suggest you re-read the line I started my reply to you with

 Also:
> > I'm not sure how a supplied URL will affect your PHP code.

> And don't top post.

Lolz.   You do not even know what "top posting" actually means, don't you.

And also, don't bottom-post (hey, if you may lay out rules than so may I
:-) )

Regards,
Rudy Wieser


-- Origional message:
Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
na21en$utt$1@jstuckle.eternal-september.org...
> On 2/17/2016 8:43 AM, R.Wieser wrote:
> > -- Origional message:
> > Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
> > na1rs4$9tp$1@jstuckle.eternal-september.org...
> >> On 2/17/2016 4:37 AM, James Harris wrote:
> >>> In line with the principle of a program vetting its input, this is
about
> >>> vetting the supplied URL.
> >>>
> >>> In order to process a URL or parts of a URL in PHP what processing
ought
> >>> to be applied to it? I have been using some steps which I will write
> >>> below but I am becoming increasingly uncertain that I have covered all
> >>> the bases.
> >>>
> >>> The main concern is safety - ensuring that the PHP code is protected
> >>> against anything that might otherwise trip it up. The second concern
is
> >>> correctness in even corner cases such as odd browsers or extended
> >>> character sets.
> >>>
> >>> I have been working with $_SERVER["REQUEST_URI"], in case that is
> > relevant.
> >>>
> >>> Steps so far:
> >>>
> >>>   urldecode to convert %nn etc
> >>>
> >>>   trim "/" from the ends in order to normalise
> >>>
> >>>   check each character is from an allowed set
> >>>
> >>>   check there are no // parts
> >>>
> >>>   check there are no .. parts
> >>>
> >>> All needed? Any not needed? Latest firefox strips out any .. entries
> >>> before sending the URL but I am not sure that all earlier browsers
> > would.
> >>>
> >>> In addition to the above, could the URL be in Unicode form? I was
> >>> thinking to change to index through it with
> >>>
> >>>   $uri[n]
> >>>
> >>> but I gather that will index bytes and not characters. Could the URL
> >>> string that PHP receives be stored as Unicode and should something
like
> >>> mb_substr be used instead?
> >>>
> >>> That's all the steps I have come up with so far. It seems a lot.
> >>> Presumably you guys have steps you use yourselves. Are all the things
I
> >>> have listed necessary? Is there anything else that should be done to
> >>> process URLs (or components thereof) safely and correctly?
> >>>
> >>> James
> >>>
> >>
> >> What are you trying to "make safe"?  A url is either good or bad.  If
> >> it's bad, it won't bring up a site.  If it's good, it will bring up a
> >> site, but that site may not be safe.
> >>
> >> What are you actually trying to accomplish here?  I'm not sure how a
> >> supplied URL will affect your PHP code.
> >>
> > Jerry,
> >
> >> What are you trying to "make safe"?  A url is either good or bad.
> >
> > I've got a name for you: "Bobby Tables".  Google it. And XKCD has got a
page
> > about him: https://xkcd.com/327/
> >
> > Regards,
> > Rudy Wieser
> >
>
> Which has absolutely nothing to do with my question.
>
> And don't top post.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

[toc] | [prev] | [next] | [standalone]

#16459

On 2/17/2016 10:39 AM, R.Wieser wrote:
> Jerry,
> 
>> Which has absolutely nothing to do with my question.
> 
> Really ?  Than I suggest you re-read the line I started my reply to you with
>

Really.

>  Also:
>>> I'm not sure how a supplied URL will affect your PHP code.
> 
>> And don't top post.
> 
> Lolz.   You do not even know what "top posting" actually means, don't you.
> 
> And also, don't bottom-post (hey, if you may lay out rules than so may I
> :-) )
> 
> Regards,
> Rudy Wieser
> 

Oh, I know what top posting is.  And I know idiots and trolls don't
follow general usenet conventions.

And in one post you've proven yourself to be both.  But then that's
pretty common for you, isn't it?

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

#16452

On 17/02/2016 13:19, Jerry Stuckle wrote:

...

> What are you trying to "make safe"?  A url is either good or bad.  If
> it's bad, it won't bring up a site.  If it's good, it will bring up a
> site, but that site may not be safe.

In this case I use url rewriting to force requests to a PHP script. The 
script then has to process the rest of the URL - basically all of the 
URL after site:port.

> What are you actually trying to accomplish here?  I'm not sure how a
> supplied URL will affect your PHP code.

At the moment I pick up $_SERVER["REQUEST_URI"]. That gives me the rest 
of the URL after the site:port part and does not strip off any ; or ? 
parts - which allows me to vet the URL including to ensure those parts 
are absent.

Does that make more sense now?

James

[toc] | [prev] | [next] | [standalone]

#16461

On 2/17/2016 10:15 AM, James Harris wrote:
> On 17/02/2016 13:19, Jerry Stuckle wrote:
> 
> ...
> 
>> What are you trying to "make safe"?  A url is either good or bad.  If
>> it's bad, it won't bring up a site.  If it's good, it will bring up a
>> site, but that site may not be safe.
> 
> In this case I use url rewriting to force requests to a PHP script. The
> script then has to process the rest of the URL - basically all of the
> URL after site:port.
> 
>> What are you actually trying to accomplish here?  I'm not sure how a
>> supplied URL will affect your PHP code.
> 
> At the moment I pick up $_SERVER["REQUEST_URI"]. That gives me the rest
> of the URL after the site:port part and does not strip off any ; or ?
> parts - which allows me to vet the URL including to ensure those parts
> are absent.
> 
> Does that make more sense now?
> 
> James
> 

James,

Yes, it helps.  But see my previous notes.  You don't need to worry
about non-ASCII characters because they won't be in the URI.  You know
that because you had to have a valid URL to get here.  But it is also
perfectly valid to have things like .. in a URL.  You just have to
ensure it doesn't allow going above the DOCUMENT_ROOT.

But you also have to ensure it doesn't go other places it shouldn't -
for instance, you may have protected directories in your DOCUMENT_ROOT
which would not normally be accessible.

You really have to separate the URL into it's individual components and
check each one individually.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.lang.php

csiph-web