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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#16509

Arno Welzel wrote:

> Thomas 'PointedEars' Lahn schrieb am 2016-02-17 um 23:33:
>> James Harris wrote:
>>> On 17/02/2016 10:05, Arno Welzel wrote:
>>>> James Harris schrieb am 2016-02-17 um 10:37:
> [...]
>>>>> In addition to the above, could the URL be in Unicode form? I was
>>>>> thinking to change to index through it with
>>>>
>>>> See RFC 1808:
>>>>
>>>> <https://tools.ietf.org/html/rfc1808>
>>> I looked through it but could not see anything about Unicode.
>> It has been obsoleted by RFC 3986 eleven(!) years ago now, which contains
>> something about Unicode, in particular it defines UTF-8 percent-encoding.
> 
> That's the problem with RFCs - nothing in the old RFC indicates the
> replacement ;-)

No, you have overlooked the “Obsoleted by:” line that is provided 
*specifically* by HTML versions of obsolete RFCs (which is why I also prefer 
to refer to the HTML versions).

Besides, the PHP Manual refers to RFC 3986 explicitly in the documentation 
of the corresponding functions: <http://php.net/url>

> But thanks for the hint.

You’re welcome.

-- 
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]

#16489

James Harris schrieb am 2016-02-17 um 16:04:

> On 17/02/2016 10:05, Arno Welzel wrote:
>> James Harris schrieb am 2016-02-17 um 10:37:
>>
>>> 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.
>>
>> Well - it depends for which reasons you want to process the URL.
> 
> It will go through a series of steps to change it and it will end up 
> identifying something in the file system or something in a database.

Ok - but in either case you end up in looking up for some information
based on what you get from the URL.

This means: Not the URL is unsafe, but the code which does the
information lookup may be unsafe.

[...]
>> There is no "normal" URL - in fact the "/" at the end is part of the URL.
> 
> The docs for request_uri (which I'll use as shorthand for the full 
> expression) did not specify whether leading or trailing slashes would be 
> present/maintained.

Yes - because it does not matter wethere there is a trailing slash or
not. Some URLs have a trailing slash, others don't. But both forms are
totally valid and there is no "normal" form with or without trailing slash.

>>>     check each character is from an allowed set
>>
>> Why?
> 
> My own insecurity, perhaps!

What do you suspect to happen if an "invalid" character is passed?
Again: Not URL itself is "unsafe" - just code which uses the information
may be unsafe.

>>>     check there are no // parts
>>
>> Why?
> 
> Because such would designate an empty path component as between "the" 
> and "bad" in http://site.com/this/is/the//bad/part.

So what? This is no problem at all, except when you write code which
relies on the fact, that there will ever by something between slashes.

In fact, using "//" doesn't even change the result in many cases:

<http://arnowelzel.de/wp/en/a-week-with-the-pebble>
<http://arnowelzel.de/wp/en//a-week-with-the-pebble>
<http://arnowelzel.de//wp//en//a-week-with-the-pebble>

>>>     check there are no .. parts
>>
>> Why?
> 
> Because that indicates the parent directory and can be used to move 'up' 
> a level in the path hierarchy. It is thus insecure.

It is only insecure, if the webserver does not sanitize the path. Apache
and nginx won't let you get outside the root directory this way.

However - if YOUR code will use that information to access a file using
the given "path" of the URL this may be a problem. But in this case you
should better use realpath() to check if the path is still within its
allowed limits.

[...]
>> As I said: It depends on what you want to achieve - do you make sure the
>> URL you get is valid? Do you want to parse the URL in any way?
> 
> The URL component (request_uri) will be mapped to a file or a database 
> entry in this case.

So why don't you just use the whole URI and use it in a prepared SELECT
statement? In that case it's just not important, what the URI contains.
Either there is an entry for that URI in the database or not. But it
doesn't matter what the URI itself contains if it's just treated as text
and used as parameter in a prepared statement.

Of course you should NOT use the URI and just add it as text in the
SELECT statement - use a pepared statement.


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

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

#16532

On 18/02/2016 07:02, Arno Welzel wrote:
> James Harris schrieb am 2016-02-17 um 16:04:
>
>> On 17/02/2016 10:05, Arno Welzel wrote:
>>> James Harris schrieb am 2016-02-17 um 10:37:
>>>
>>>> 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.
>>>
>>> Well - it depends for which reasons you want to process the URL.
>>
>> It will go through a series of steps to change it and it will end up
>> identifying something in the file system or something in a database.
>
> Ok - but in either case you end up in looking up for some information
> based on what you get from the URL.
>
> This means: Not the URL is unsafe, but the code which does the
> information lookup may be unsafe.

Yes, though in those terms I don't think there is ever any unsafe input, 
only unsafe code which fails to handle the input properly.

...

>>>>      check each character is from an allowed set
>>>
>>> Why?
>>
>> My own insecurity, perhaps!
>
> What do you suspect to happen if an "invalid" character is passed?
> Again: Not URL itself is "unsafe" - just code which uses the information
> may be unsafe.

Well, as was pointed out to me, after passing the request_uri through 
(raw)urldecode the resulting string might not have ASCII coding and so 
would not be suitable for byte-wise processing. That is a bit of a gotcha.

...

>>> As I said: It depends on what you want to achieve - do you make sure the
>>> URL you get is valid? Do you want to parse the URL in any way?
>>
>> The URL component (request_uri) will be mapped to a file or a database
>> entry in this case.
>
> So why don't you just use the whole URI and use it in a prepared SELECT
> statement? In that case it's just not important, what the URI contains.

Yes, I suppose I could do that for file access too. I was/am just wary 
of presenting an input string to any function without vetting that 
string first, even with a prepared statement as you mentioned.

I *can* see the prepared-statement option should work. I am less sure 
what would happen if I presented an unvetted string to a file- or 
directory-access function.

Thanks to everyone for the advice. The best option seems to be along the 
lines of:

1. rawurldecode

2. check that the result is ASCII coded

3. add a leading slash if there is not one

4. split by slash characters

5. check that each part is nonblank and has a suitable form for a key

I might add a check that all letters are lower case. That would help 
generate a consistent response irrespective of the OS the script were to 
run on.

James

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

#16542

James Harris wrote:

> Well, as was pointed out to me, after passing the request_uri through
> (raw)urldecode the resulting string might not have ASCII coding and so

ASCII _encoding_, and it *certainly* is not encoded using US-ASCII.
AISB, US-ASCII is a *7*-bit encoding.

> would not be suitable for byte-wise processing. That is a bit of a gotcha.

<http://php.net/manual/en/ref.mbstring.php>
 
> 2. check that the result is ASCII coded

Superfluous if you can handle different encodings.  Unicode support in 
databases and filenames, for example, is common nowadays.  PHP is oblivious 
to the character encoding of a string (you need to tell it), which only is a 
problem if you need to access individual characters (and then see above for 
the solution).
 
> 3. add a leading slash if there is not one

To what end?
 
> 4. split by slash characters

That would leave an empty first element of the resulting array, …
 
> 5. check that each part is nonblank and has a suitable form for a key

… so this test would fail.

I still think that your approach is wrong, but unless you state your use-
case in more detail, I cannot be certain.

> I might add a check that all letters are lower case. That would help
> generate a consistent response irrespective of the OS the script were to
> run on.

So you are mapping URI paths to files.  Know then that it is not so much a 
matter of the operating system, but of the *file* system how filenames
are handled.  Also, it is inherently unsafe.  Why are you doing this?

-- 
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]

#16546

On 20/02/2016 20:37, Thomas 'PointedEars' Lahn wrote:
> James Harris wrote:
>
>> Well, as was pointed out to me, after passing the request_uri through
>> (raw)urldecode the resulting string might not have ASCII coding and so
>
> ASCII _encoding_, and it *certainly* is not encoded using US-ASCII.
> AISB, US-ASCII is a *7*-bit encoding.

I know. As with a previous post of yours that I haven't got round to 
replying to yet I was referring to the report from mb_detect_encoding(). 
It reports ASCII or UTF-8 in my tests. I can choose to permit only ASCII 
strings.

>> would not be suitable for byte-wise processing. That is a bit of a gotcha.
>
> <http://php.net/manual/en/ref.mbstring.php>

Thanks. I have a lot to read.

...

>> 3. add a leading slash if there is not one
>
> To what end?

I thought that I got a response from one test where the result did not 
have a leading slash. I didn't make a note of the details so am not so 
sure now but it does not matter much. Forcing there to be a leading 
slash costs next to nothing, guards against the possibility of that 
happening, and makes later processing (including certain misbehaving PHP 
functions) simpler.

>> 4. split by slash characters
>
> That would leave an empty first element of the resulting array, …
>
>> 5. check that each part is nonblank and has a suitable form for a key
>
> … so this test would fail.

Yes. I was not as precise in my description as I was in the code.

> I still think that your approach is wrong, but unless you state your use-
> case in more detail, I cannot be certain.
>
>> I might add a check that all letters are lower case. That would help
>> generate a consistent response irrespective of the OS the script were to
>> run on.
>
> So you are mapping URI paths to files.  Know then that it is not so much a
> matter of the operating system, but of the *file* system how filenames
> are handled.  Also, it is inherently unsafe.  Why are you doing this?

Not exactly. Let me take a small step backwards to try to explain better.

The idea is, first, that the entire URL is a globally unique key for the 
data being addressed. Except as defined by certain rules which 
complicate this a bit but are not relevant here there should not be 
multiple URLs which map to the same data. I therefore vet the URLs that 
my PHP script sees to make sure that they do not contain any redundant 
information, and I do not allow directory manipulations such as are 
often allowed for filesystem access (especially dot and double-dot entries).

Second, the elements of the URL are not filesystem locations. They are 
keys. My current code maps those keys to directories but it could just 
as well map them to something else like a database.

Third, the URLs are to be permanent or as long-lasting as is feasible. A 
given URL should remain valid even if the underlying storage system is 
changed. Basically, the unique URLs and the keys they contain are 
intended to outlive the implementation method.

IMO it is best initially to require that the keys (which are presented 
to the PHP script by means of the URL) be simple. Restrictions can then 
be relaxed without breaking existing URLs.

Do you still think that the approach is unsafe?

James

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

#16569

James Harris wrote:

> On 20/02/2016 20:37, Thomas 'PointedEars' Lahn wrote:
>> James Harris wrote:
>>> I might add a check that all letters are lower case. That would help
>>> generate a consistent response irrespective of the OS the script were to
>>> run on.
>> So you are mapping URI paths to files.  Know then that it is not so much
>> a matter of the operating system, but of the *file* system how filenames
>> are handled.  Also, it is inherently unsafe.  Why are you doing this?
> Not exactly. Let me take a small step backwards to try to explain better.
> 
> The idea is, first, that the entire URL is a globally unique key for the
> data being addressed.

That is implicit, you do not need PHP for it.

> Except as defined by certain rules which complicate this a bit but are not
> relevant here there should not be multiple URLs which map to the same 
> data.

Also implicit, hence Uniform Resource *Identifier*.

> I therefore vet the URLs that my PHP script sees to make sure that they do
> not contain any redundant information,

Such as?

> and I do not allow directory manipulations such as are
> often allowed for filesystem access (especially dot and double-dot
> entries).

You would not have that problem if you would not access the filesystem 
through PHP in the first place.
 
> Second, the elements of the URL are not filesystem locations. They are
> keys. My current code maps those keys to directories but it could just
> as well map them to something else like a database.

That does not mean that every request URI needs to be rewritten to the same 
PHP program.

> Third, the URLs are to be permanent or as long-lasting as is feasible. A
> given URL should remain valid even if the underlying storage system is
> changed. Basically, the unique URLs and the keys they contain are
> intended to outlive the implementation method.

Server-side redirection can take care of that, too.

<https://www.w3.org/QA/Tips/reback>
 
> IMO it is best initially to require that the keys (which are presented
> to the PHP script by means of the URL) be simple. Restrictions can then
> be relaxed without breaking existing URLs.
> 
> Do you still think that the approach is unsafe?

More than that; I think it is nonsense.  But as you keep being nebulous I am 
getting the impression that I am wasting my precious time with this.

<http://meta.stackexchange.com/a/66378/178570>

-- 
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]

#16571

On 21/02/2016 14:02, Thomas 'PointedEars' Lahn wrote:

...

> More than that; I think it is nonsense.  But as you keep being nebulous I am
> getting the impression that I am wasting my precious time with this.

You have recently been talking about things which are not relevant to 
what I asked so while I thank you for the earlier points you made which 
were useful I agree with you that it's best for you not to waste any 
more of your time on this topic.

James

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

#16443

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.

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

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

#16444

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


-- 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.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

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

#16445

R.Wieser schrieb am 2016-02-17 um 14:43:

> 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/

And what do SQL injections have to do with "safe URL"?


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

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

#16446

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


-- Origional message:
Arno Welzel <usenet@arnowelzel.de> schreef in berichtnieuws
56C47E05.10508@arnowelzel.de...
> R.Wieser schrieb am 2016-02-17 um 14:43:
>
> > 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/
>
> And what do SQL injections have to do with "safe URL"?
>
>
> --
> Arno Welzel
> http://arnowelzel.de
> http://de-rec-fahrrad.de
> http://fahrradzukunft.de

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

#16447

R.Wieser schrieb am 2016-02-17 um 15:17:

> 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.

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.

And maybe you should also see my other post
<56C445F6.1090008@arnowelzel.de> which I just sent a couple hours ago
(before your post) where I refer to possible security risks - including
SQL injection.


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

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

#16450

Arno,

> How does an *URL* itself cause an SQL injection?

How does a bug in a PHP script *cause* a malfunction ?   And no, if you do
not allow it to reach execution it won't.   Your point ?

> And maybe you should also see my other post

... and maybe you should have noticed I was replying to what *Jerry* said.

Regards,
Rudy Wieser


-- Origional message:
Arno Welzel <usenet@arnowelzel.de> schreef in berichtnieuws
56C487FA.1070401@arnowelzel.de...
> R.Wieser schrieb am 2016-02-17 um 15:17:
>
> > 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.
>
> 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.
>
> And maybe you should also see my other post
> <56C445F6.1090008@arnowelzel.de> which I just sent a couple hours ago
> (before your post) where I refer to possible security risks - including
> SQL injection.
>
>
> --
> Arno Welzel
> http://arnowelzel.de
> http://de-rec-fahrrad.de
> http://fahrradzukunft.de

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

#16458

On 2/17/2016 9:57 AM, R.Wieser wrote:
> Arno,
> 
>> How does an *URL* itself cause an SQL injection?
> 
> How does a bug in a PHP script *cause* a malfunction ?   And no, if you do
> not allow it to reach execution it won't.   Your point ?
> 
>> And maybe you should also see my other post
> 
> ... and maybe you should have noticed I was replying to what *Jerry* said.
>

Yes, and showing your ignorance in doing so.

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

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

#16462

Jerry,

> Yes, and showing your ignorance in doing so.

And you seem to revell in saying "you're wrong" without even *trying* to
explain why.

... that makes me think of a puffer fish: pumping himself up trying to bluff
his way around problems . :-)

And by all means, "put your money where your mouth is" and at least *try* to
explain how all of what I say is ignorant.   I don't think you're up to it
(prove me wrong).

Regards,
Rudy Wieser


-- Origional message:
Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
na253l$nkl$3@jstuckle.eternal-september.org...
> On 2/17/2016 9:57 AM, R.Wieser wrote:
> > Arno,
> >
> >> How does an *URL* itself cause an SQL injection?
> >
> > How does a bug in a PHP script *cause* a malfunction ?   And no, if you
do
> > not allow it to reach execution it won't.   Your point ?
> >
> >> And maybe you should also see my other post
> >
> > ... and maybe you should have noticed I was replying to what *Jerry*
said.
> >
>
> Yes, and showing your ignorance in doing so.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

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

#16463

On 2/17/2016 11:10 AM, R.Wieser wrote:
> Jerry,
> 
>> Yes, and showing your ignorance in doing so.
> 
> And you seem to revell in saying "you're wrong" without even *trying* to
> explain why.
>

If you had a brain in your head, you would understand that a URL has
nothing to do with deleting tables in a SQL database.

> ... that makes me think of a puffer fish: pumping himself up trying to bluff
> his way around problems . :-)
> 
> And by all means, "put your money where your mouth is" and at least *try* to
> explain how all of what I say is ignorant.   I don't think you're up to it
> (prove me wrong).
> 
> Regards,
> Rudy Wieser
> 
> 

You obviously don't even understand SQL injection.  You just know how to
paste the URL to a cartoon (which is completely unrelated to the OP's
question) in a message.

But then you've done similar things in other newsgroups and are well
known as a troll there.

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

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

#16465

Jerry,

> If you had a brain in your head, you would understand that a URL has
> nothing to do with deleting tables in a SQL database.

If trhats the case than I count myself lucky *not* to have a brain
(especially not one like yours), as pretty much everyone else than you seems
to understand the problem with an URL, or any kind of unsanitized input that
could be fed to a SQL database.  Hence that XKCD strip.

Regards,
Rudy Wieser


-- Origional message:
Jerry Stuckle <jstucklex@attglobal.net> schreef in berichtnieuws
na29e0$a65$1@jstuckle.eternal-september.org...
> On 2/17/2016 11:10 AM, R.Wieser wrote:
> > Jerry,
> >
> >> Yes, and showing your ignorance in doing so.
> >
> > And you seem to revell in saying "you're wrong" without even *trying* to
> > explain why.
> >
>
> If you had a brain in your head, you would understand that a URL has
> nothing to do with deleting tables in a SQL database.
>
> > ... that makes me think of a puffer fish: pumping himself up trying to
bluff
> > his way around problems . :-)
> >
> > And by all means, "put your money where your mouth is" and at least
*try* to
> > explain how all of what I say is ignorant.   I don't think you're up to
it
> > (prove me wrong).
> >
> > Regards,
> > Rudy Wieser
> >
> >
>
> You obviously don't even understand SQL injection.  You just know how to
> paste the URL to a cartoon (which is completely unrelated to the OP's
> question) in a message.
>
> But then you've done similar things in other newsgroups and are well
> known as a troll there.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> jstucklex@attglobal.net
> ==================

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

#16466

On 2/17/2016 12:51 PM, R.Wieser wrote:
> Jerry,
> 
>> If you had a brain in your head, you would understand that a URL has
>> nothing to do with deleting tables in a SQL database.
> 
> If trhats the case than I count myself lucky *not* to have a brain
> (especially not one like yours), as pretty much everyone else than you seems
> to understand the problem with an URL, or any kind of unsanitized input that
> could be fed to a SQL database.  Hence that XKCD strip.
> 
> Regards,
> Rudy Wieser
> 
>

Except the OP said NOTHING about feeding it to a SQL database.  But
top-posting idiot trolls can't understand simple questions.

No go crawl back into your Windows newsgroups.  Or don't they talk to
trolls, either?

Because I'm done feeding the troll.

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

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

#16468

R.Wieser schrieb am 2016-02-17 um 15:57:

> Arno,
> 
>> How does an *URL* itself cause an SQL injection?
> 
> How does a bug in a PHP script *cause* a malfunction ?   And no, if you do
> not allow it to reach execution it won't.   Your point ?

My point is, that an URL itself is just an URL - and your reference to
SQL injection in this context doesn't make any sense at all.

BTW: at least you should think about your way to quote posts.


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

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

#16471

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 your reference to SQL injection in this context doesn't
> make any sense at all.

Are you sure ?

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 ...

> 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.

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).

I seldom (if ever) make a remark about it though, as everyone has got his
own preferences.

As for my style ?     Remove anything from the "-- Origional message:"* line
down, and my post is *still* readable.   Compare that to any of the above.

*which should have been a "bit" of a hint ....

And for the record: you can consider the part following the "-- Origional
message:" line as an addendum.   You mostly will not need it (especially not
when in a well-functioning newgroup like this one), but it can be used to
check if anything is quoted outof context, or, when finding the message
somewhere in the future and all on its own, to get a feeling what post is
actually reponding to.

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

Regards,
Rudy Wieser


-- Origional message:
Arno Welzel <usenet@arnowelzel.de> schreef in berichtnieuws
56C4B6AD.9070900@arnowelzel.de...
> R.Wieser schrieb am 2016-02-17 um 15:57:
>
> > Arno,
> >
> >> How does an *URL* itself cause an SQL injection?
> >
> > How does a bug in a PHP script *cause* a malfunction ?   And no, if you
do
> > not allow it to reach execution it won't.   Your point ?
>
> My point is, that an URL itself is just an URL - and your reference to
> SQL injection in this context doesn't make any sense at all.
>
> BTW: at least you should think about your way to quote posts.
>
>
> --
> Arno Welzel
> http://arnowelzel.de
> http://de-rec-fahrrad.de
> http://fahrradzukunft.de

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

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

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

csiph-web