Eric Butera emailed me with a very interesting topic about protecting against PHP_SELF exploits. I thought it might be a good idea to gather a few test cases demonstrating the problem. Why PHP allows these URL’s is beyond me and it wouldn’t take much work to filter out these malicious URL’s in the PHP code.
For any of you that don’t know, it’s possible to inject code into PHP_SELF. It works by supplying a “/” after the actual PHP file then entering your desired code. I’ve done 4 test cases which show how it’s possible to inject javascript and perform a redirect on code which doesn’t filter PHP_SELF correctly.
Test case 1
Injects data into a HTTP header, although this scenario is not very likely I thought I would include it to show that even running htmlentities or htmlspecialchars won’t save you from attack completely.
Test case 2
Shows how easy it is to inject XSS into links, this is very likely as many PHP applications ofter refer to the same page to change the current action/display.
Test case 3
A search page often includes references to PHP_SELF and can be exploited as easily as links.
Test case 4
Finally I show how code can be injected directly on the page without the need to break out of anything.
The test cases can be downloaded here:-
Test cases
Comments 10
I think all these are cases of XSS bugs. Escape the content correctly and you won’t have any problem. On the other side, I prefer to use REQUEST_URI as it also works with “user-friendly” (mod_rewrited) URLs.
<?php echo htmlspecialchars($_SERVER['REQUEST_URI']) ?>
Posted 14 Jan 2008 at 3:20 pm ¶@Francesc
Yep that’s why I provided the test cases so that developers are aware that they should escape the data correctly. 2-4 are XSS issues and test case 1 deals with http header injection and redirection.
Posted 14 Jan 2008 at 3:29 pm ¶I blogged about this 2.5 years ago, here: http://blog.phpdoc.info/archives/13-XSS-Woes.html
(-:
S
Posted 14 Jan 2008 at 3:41 pm ¶@Sean
Yeah that’s pretty bad, I know it isn’t new but a reader asked me the question so it can’t do any harm bringing the subject up again.
Posted 14 Jan 2008 at 3:52 pm ¶@Francesc:
You need to use ENT_QUOTES as the second parameter just in case because by default ‘ will not be encoded.
@Gareth:
Posted 14 Jan 2008 at 3:58 pm ¶Thank you for the time for this post! Hopefully now this will be enough to convince the powers that be to fix this stuff.
@Eric:
I didn’t know it. Thanks! Luckily I don’t use single quotes at HTML level.
Anyway I’m gonna change my HTML escaping function to this:
function eh ($string)
{
echo htmlspecialchars($string, ENT_QUOTES);
}
Being so essential, I don’t understand why PHP doesn’t have something like this built in.
Posted 14 Jan 2008 at 8:00 pm ¶@Eric:
There is noone to convince to fix this stuff. PHP_SELF is filled by the webserver. Apache supports PATH_INFO therefore this kind of path ends up in PHP_SELF.
This problem is known for ages and still many sites are vulnerable to this…
And well there is always the possibility to just install the Suhosin Extension and you are automatically secure from this kind of XSS.
Posted 14 Jan 2008 at 8:51 pm ¶Hi,
Posted 14 Jan 2008 at 11:55 pm ¶You might want to escape the variable in header() by calling either urlencode(), and that should be enough. Please remember that each output medium has its proper escaping mechanism. The injection there happens mostly because you don’t escape the output.
Regards,
the test 1 fails on PHP 5.2.4 without any special extension, etc
Posted 15 Jan 2008 at 5:53 am ¶The error I get is “Warning: Header may not contain more than a single header, new line detected. in /var/www/htdocs/php_self.php on line 4″
The other 3 tests do work as expected.
<form method=POST action=”<?php echo $PHP_SELF;’SelectedState=$SelectedState’ ?>” >
in the above line i am trying to pass a variables value onto the same page but its not working can anyone suggest me the syntax
Posted 27 May 2008 at 8:13 am ¶Post a Comment