A XSS Vulnerability in Almost Every PHP Form I’ve Ever Written
I've spent a lot of time over the past few months writing an enterprise application in PHP. Despite what some people may say, I believe that PHP is as secure or insecure as the developer who is writing the code. Anyway, I'm at the point in my development lifecycle where I decided that it was ready to run an application vulnerability scanner against it. What I found was interesting and I think it's worth sharing with you all.
Let me preface this by saying that I'm the guy who gives the training to our developers on the OWASP Top 10, writing secure code, etc. I'd like to think that I have a pretty good handle on programming best practices, input validation, and HTML encoding. I built all kinds of validation into this application and thought that the vulnerability scan would come up empty. For the most part I was right, but there was one vulnerability, one flaw in particular, that found it's way into every form in my application. In fact, I realized that I've made this exact same mistake in almost every PHP form that I've ever written. Talk about a humbling experience.
So here's what happened. I created a simple page with a form where the results of that form are submitted back to the page itself for processing. Let's assume it looks something like this:
<html> <body> <?php if (isset($_REQUEST['submitted']) && $_REQUEST['submitted'] == '1') { echo "Form submitted!"; } ?> <form action="<?php echo $_SERVER['PHP_SELF']; ?>"> <input type="hidden" name="submitted" value="1" /> <input type="submit" value="Submit!" /> </form> </body> </html>
It looks fairly straightforward, right? The problem has to do with that $_SERVER['PHP_SELF'] variable. The intent here is that PHP will display the path and name of the current page so that the form knows to submit back to the same page. The problem is that $_SERVER['PHP_SELF'] can actually be manipulated by the user. Let's say as the user I change the URL from http://www.webadminblog.com/example.php to http://www.webadminblog.com/example.php"><script>alert('xss');</script>. This will end the form action part of the code and inject a javascript alert into the page. This is the very definition of cross site scripting. I can't believe that with as long as I've been writing in PHP and as long as I've been studying application security, I've never realized this. Fortunately, there are a couple of different ways to fix this. First, you could use the HTML entities or HTML special character functions to sanitize the user input like this:
htmlentities($_SERVER['PHP_SELF]);
htmlspecialchars($_SERVER['PHP_SELF]);
This fix would still allow the user to manipulate the URL, and thus, what is displayed on the page, but it would render the javascript invalid. The second way to fix this is to use the script name variable instead like this:
$_SERVER['SCRIPT_NAME'];
This fix would just echo the full path and filename of the current file. Yes, there are other ways to fix this. Yes, my code example above for the XSS exploit doesn't do anything other than display a javascript alert. I just wanted to draw attention to this issue because if it's found it's way into my code, then perhaps it's found it's way into yours as well. Happy coding!
February 24th, 2010 - 05:14
http://seancoates.com/xss-woes
February 24th, 2010 - 07:40
When my application vulnerability scanner found the vulnerability I started searching around in Google and that was the very first page that came up and how I figured out the fix for the issue. Big thanks to Sean for writing that and everyone who commented on it afterward. An excellent blog post.
February 24th, 2010 - 13:46
Yeah, seems like there should be an almost automatic routine to scrub all that “other” user input before it even gets put into the variables. All HTTP headers, cookies… Anything else from the HTTP request you’re tempted to use like user-agent all suffer from the same problem.
February 25th, 2010 - 23:39
Ernest, you just described http://php.net/filter which lets you set a default filter that is applied to all user data.
March 2nd, 2010 - 03:16
But… index.php” isn’t a valid URL?
March 2nd, 2010 - 03:17
(Incidentally, if you want a script to post back to itself, it’s easier just to leave out the action=”" part altogether in your tag).
November 11th, 2010 - 21:13
this is also supposed to be open to XSS issues (and is considered “bad form”):
quote: (Incidentally, if you want a script to post back to itself, it’s easier just to leave out the action=”” part altogether in your tag).
November 12th, 2010 - 08:38
I am wondering is it a vulnerability when a script has a form on it that posts to itself?
November 12th, 2010 - 08:43
I’m not exactly sure why a script having a form that posts to itself would be considered a vulnerability in and of itself, but without proper input validation and output encoding, there’s a high likelihood that you’ll find actual vulnerabilities in that script.
~josh
November 21st, 2010 - 18:26
Great post, very helpful. I have created several projects in much the same way. Thanks for the insight regarding $_SERVER['SCRIPT_NAME']. There are a lot of similar posts out there, but very few of them explain or even suggest using SCRIPT_NAME instead of PHP_SELF.
April 19th, 2011 - 17:44
Am I missing something?
If the user knowingly manipulates $_SERVER['PHP_SELF'] in the context of submitting a form then all they can do is inject Javascript into a page that only they themselves are viewing.
That must be a proud moment when you fall to an XSS attack of your own doing?
April 26th, 2011 - 15:49
Ben, the idea behind reflected cross-site scripting is that the attacker crafts a malicious URL and then tries to manipulate the victim (usually via some form of social engineering) into clicking on the link. So if you take my example above using http://www.webadminblog.com/example.php“><script>alert(‘xss’);</script>, you’d see that if someone were tricked into going to that URL, they would indeed trigger the JavaScript which was embedded into the link. So the user is not falling into their own XSS as you put it, they are falling into the attackers. The real issue behind this attack, however, is that the script gets executed within the victim’s browser. This means that the attacker could steal the victim’s cookies, use their login credentials to make requests (CSRF), create fake login forms, change page content, etc. Does that make sense?
April 26th, 2011 - 20:03
Not following this at all – when I tried it, the page failed to load as that url didn’t exist.
Did you mean to make it a parameter?
eg
http://www.webadminblog.com/example.php?“>alert(‘xss’);
But when I tried that, the browser encoded the brackets. Are there browsers that don’t do that?
Fortunately, I still know I haven’t made this mistake – the first thing I do is check that the path is the correct one, and 301 to the proper page if it isn’t. I do this for SEO reasons; its nice to know its helped security
April 29th, 2011 - 17:06
Right, I get it now, thanks for the clarification. Very dangerous stuff.
May 11th, 2011 - 14:21
Thanks for the “$_SERVER['SCRIPT_NAME']” pointer – so simple – cannot believe that had not occurred to me…
May 13th, 2011 - 10:03
Lea, some of the newer browsers have built in some XSS defenses. The newer versions of IE, for example, will display a message in the bar at the top saying that it blocked a potential XSS attack. Also, my example is just a sample of what a URL would look like but it does not actually exist which could also be creating issues. In any case, yes there are browsers that are vulnerable to XSS and the only way to completely prevent a XSS exploit from an end-user perspective is to turn off JavaScript in your browser. Unfortunately, that breaks a good portion of other web functionality as well.
January 10th, 2012 - 15:14
or just simply use <form action="" or action="."