On Sun, Jan 29, 2012 at 11:38 AM, Tedd Sperling tedd.sperl...@gmail.comwrote:
On Jan 27, 2012, at 12:45 PM, Adam Richardson wrote:
On Fri, Jan 27, 2012 at 12:09 PM, Tedd Sperling tedd.sperl...@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
--
Nephtali: A simple, flexible, fast, and security-focused PHP framework
http://nephtaliproject.com
