Exploiting PHP SELF
Monday, 14 January 2008
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
No. 1 — January 14th, 2008 at 3:20 pm
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’]) ?>
No. 2 — January 14th, 2008 at 3:29 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.
No. 3 — January 14th, 2008 at 3:41 pm
I blogged about this 2.5 years ago, here: http://blog.phpdoc.info/archives/13-XSS-Woes.html
(-:
S
No. 4 — January 14th, 2008 at 3:52 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.
No. 5 — January 14th, 2008 at 3:58 pm
@Francesc:
You need to use ENT_QUOTES as the second parameter just in case because by default ‘ will not be encoded.
@Gareth:
Thank you for the time for this post! Hopefully now this will be enough to convince the powers that be to fix this stuff.
No. 6 — January 14th, 2008 at 8:00 pm
@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.
No. 7 — January 14th, 2008 at 8:51 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.
No. 8 — January 14th, 2008 at 11:55 pm
Hi,
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,
No. 9 — January 15th, 2008 at 5:53 am
the test 1 fails on PHP 5.2.4 without any special extension, etc
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.
No. 10 — May 27th, 2008 at 8:13 am
<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
No. 11 — August 12th, 2008 at 3:31 am
If you want to past variable on the same page you need to pass it by using GET statement.
No. 12 — August 27th, 2008 at 2:23 pm
Bipin, Busby is wrong, apparently he doesn’t understand what this page is about… this is how you do it. Note however, that as this page is describing, this can be exploited.
<form method=”post” action=”<?php echo $_SERVER[‘PHP_SELF’]; ?>”>
<!– My Form –>
</form>
Check out this page also:
http://www.gfx-depot.com/forum/-php-server-php-self-validation-t-1636.html
No. 13 — December 21st, 2008 at 6:51 am
Um… have people never heard of local/relative urls????
saying <a href='<?php echo $_SERVER[PHP_SELF]?>/cow/lame.php’>link</a> is a retarded waste of time.
try <a href=’cow/lame.php’ >link</a> or for a form action, action=”…. not ‘action='<?php blah blah self?>
it’s such a waste of time.
No. 14 — March 11th, 2009 at 12:22 am
@j squid, local/relative urls are fine and dandy however is not always a possible solutions. Certain senarios simply require a full path.
Let’s say for example that I want to redirect ppl to the former page so you need to pass the current page to the next. PHP_SELF is very useful. Just escape and validate properly and you’ll be fine.
No. 15 — May 14th, 2009 at 8:54 pm
What kind of harm this could possibly (but realistically) do, except for displaying some modified html to the “hacker” HIMSELF (only) ?
i mean i don’t see a way to alternate php code itself or displaying some useful info like database structure or php source code using this exploit…
please explain!
No. 16 — May 14th, 2009 at 9:04 pm
I mean you could probably spam in emails a crafted link to legitimate web site, where at the end of file name it will send user cookies for example to some web-based email sender.
so the link will look ok in spammer’s email, and so users will probably click on it…
ok, i guess it make sense to validate php_self after all…
No. 17 — May 23rd, 2009 at 12:19 am
Use SCRIPT_NAME instead of PHP_SELF