[prev in list] [next in list] [prev in thread] [next in thread] 

List:       php-general
Subject:    Re: [PHP] differences in between these env. variables
From:       Tedd Sperling <tedd.sperling () gmail ! com>
Date:       2012-01-31 17:53:29
Message-ID: BA855400-1B67-4D97-BFB4-FD8489AAC281 () gmail ! com
[Download RAW message or body]


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_Che \
> at_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






--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php


[prev in list] [next in list] [prev in thread] [next in thread]