Re: differences in between these env. variables
| From: | Tedd Sperling | Date: | Tue, 31 Jan 2012 17:53:29 +0000 |
| Subject: | Re: differences in between these env. variables | ||
| References: | 1 2 3 4 5 6 7 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-316440@lists.php.net to get a copy of this message | ||
On Jan 29, 2012, at 7:01 PM, Adam Richardson wrote:
> On Sun, Jan 29, 2012 at 11:38 AM, Tedd Sperling <tedd.sperling@gmail.com> wrote:
> On Jan 27, 2012, at 12:45 PM, Adam Richardson wrote:
>
> > On Fri, Jan 27, 2012 at 12:09 PM, Tedd Sperling <tedd.sperling@gmail.com> wrote:
> > On Jan 11, 2012, at 9:24 PM, tamouse mailing lists wrote:
> >
> > > Is there ever a case where SCRIPT_NAME does not equal PHP_SELF?
> >
> > Was this every answered? I would like to know.
> >
> > Cheers,
> >
> > tedd
> >
> > Yep, can be different:
> >
> > http://stackoverflow.com/questions/279966/php-self-vs-path-info-vs-script-name-vs-request-uri
> >
> > Adam
>
> I should have been more clear -- I understand:
>
> [PHP_SELF] => /test.php/foo/bar
> [SCRIPT_NAME] => /test.php/
>
> by practice is different.
>
> I should have used basename() in my question.
>
> The main point I was trying to get was which one is more secure and not subject to cross-site
> scripting or other such security issues?
>
> IOW, if you had to bet your life on it, which would be most secure in reporting an accurate
> basename()?
>
> That's an interesting question.
>
> Because $_SERVER['SCRIPT_NAME'] doesn't include path info appended to the get
> request, it greatly limits the attack surface, so I try to use it when I can. However, there are
> times when you want the ability to pass in additional path info (e.g., pretty urls), and that makes
> $_SERVER['PHP_SELF'] quite useful.
>
> In terms of securely using $_SERVER['PHP_SELF'], the one thing I don't ever
> recommend is trying to sanitize input (this view is in stark contrast to some of the resources
> online that detail how to safely use $_SERVER['PHP_SELF'] through a combination of
> techniques including sanitization.) I suggest that any time script receives that doesn't meet
> its expectations, the script should throw away the data and kindly communicate to the user that
> they'll have to try the request again with valid data.
>
> To use $_SERVER['PHP_SELF'] safely, the most important thing is context. In order for
> an XSS attack to succeed, it has to sneak in data that is structurally meaningful in the context of
> its use. If the web page outputs $_SERVER['PHP_SELF'] in an href such as the one below,
> then a double quote (or any of its possible encodings which buggily sneak through older browsers,
> but modern browsers seem to have corrected many of these issues) must be escaped:
>
> // if a double quote comes through PHP_SELF here and is not escaped, we're in trouble
> //
> https://www.owasp.org/index.php/XSS_(Cross_Site_Scripting)_Prevention_Cheat_Sheet#RULE_.232_-_Attribute_Escape_Before_Inserting_Untrusted_Data_into_HTML_Common_Attributes
> <a href="<?php echo $_SERVER['PHP_SELF']; ?>">Link back to this
> page</a>
>
> So, in the above case, I would first filter the PHP_SELF value through a regex that establishes
> a whitelist of valid values and/or characters (if you know all the possible paths of your app ahead
> of time, make sure there's a match; if you know that the path info only includes letters a-z,
> make sure there are they are the only characters you allow; etc.), and then for valid input, escape
> the output using htmlspeciachars().
>
> NOTE: Developers who fail don't use quotes on attributes would have to be much more
> careful and escape several other characters in the above example.
>
> That all said, if PHP_SELF was being echoed out into a script tag, the above technique would be
> insufficient to protect against XSS, as the content of the script tag has many more structurally
> meaningful characters that have to be watched for and escaped.
>
> So, it really varies by the context of use. I'd use SCRIPT_NAME where I don't need
> the path info (but I'd still likely whitelist it's possible values and escape it's
> output.) And, if I needed the path info, I'd whitelist the possible PHP_SELF values and then
> escape the output according to the context.
>
> That all said, if my life depended on security of the app, I'd probably be very slow to
> put up any web pages, as the amount of testing and auditing I'd want to perform would be on the
> scale of years ;)
>
> Adam
Adam:
Thank you for your most thoughtful answer -- it was very informative. I won't be using
"echo $_SERVER['PHP_SELF'];" for any forms or links.
Cheers,
tedd.
_____________________
tedd@sperling.com
http://sperling.com