Risk of using $_SERVER['REQUEST_URI'] or $_SERVER['PHP_SELF'] in forms and links

Question

Is there any risk of using $_SERVER['REQUEST_URI'] or $_SERVER['PHP_SELF'] as the action in a form or as the href in a link?

If so, what can be done to alleviate the risk?

Answer 1

You make a form on www.example.com/form.php. A year from now, you forget the URL is just grabbing whatever URL the page is loaded on.

At some point let's say you've added a 'delete everything' global option in your framework as part of a completely different (slightly odd) request.

Now, somebody sends you this link: www.example.com/form.php?delete_everything=true. Since you're just grabbing that URL and setting it as the action, that is now the action on your form. Oops. XSS attacks work essentially in this way.

Always assume that your code is going to be used (even by you, and especially by hackers) in ways that you don't expect when you first write it.

How do you get round it? Hardcode the URL! You can include a function which returns the URL. In effect, this is how frameworks like Symfony or CodeIgniter solve it.

Answer 2

This is because $_SERVER['PHP_SELF'] and $_SERVER['REQUEST_URI'] can be manipulated in a way whereby, if you don't escape it properly, it can be used in XSS attacks.

Much this is made possible by the fact that a URL like this will work just fine:

/path/to/index.php/" onmouseover="alert('hi')

Let's use this code:

<form action="<?php echo $_SERVER['PHP_SELF']; ?>">
...
</form>

It calls /path/to/index.php, i.e. the SCRIPT_NAME, but when you just echo $_SERVER['PHP_SELF'] it will break your intended HTML.

<form action="/path/to/index.php/" onmouseover="alert('hi')">
...
</form>

Solutions

In many cases, using <form action=""> is enough to make the form post to the script itself. Otherwise, if you know the script is called "bla.php", then set action="bla.php".

Answer 3

$_SERVER is vulnerable to XSS attacks, and should be cleansed using htmlspecialchars() prior to use.

An example injection:

   <form method="post" action="<?php echo $_SERVER['PHP_SELF']; ?>"></form>

Now call the form with the following with the injection:

http://www.example.com/form.php/%22%3E%3Cscript%3Ealert(‘xss attack’)%3C/script%3E%3Cbr%20class=%22irrelevant

Always remember to clean input data ... ALWAYS!

Answer 4

I realize this is a pretty old post, but it's an issue that I struggled with as well some time ago. What I do now days is this:

$php_self = filter_input(INPUT_SERVER, 'PHP_SELF', 522);
define('PHP_SELF', $php_self);

With this, you can safely use the constant PHP_SELF as the form action. What this bit of code does is run the super global $_SERVER['PHP_SELF'] through a filter while assigning the result as the variable $php_self. The ID number 522 refers to FILTER_SANITIZE_FULL_SPECIAL_CHARS which removes the ability for someone to inject javascript and such.

You can see which filters are available with this bit of code here:

<table>
<tr><td>Filter Name</td><td>Filter ID</td></tr>
<?php
foreach(filter_list() as $id =>$filter)
{
  echo '<tr><td>'.$filter.'</td><td>'.filter_id($filter).'</td></tr>'."n";
}
?>
</table>

The same principle can be applied to most, if not all of the super global $_SERVER variables.

Below are some of my favorites to play with:

# FILTER_SANITIZE_STRING or _STRIPPED
$server_http_xrw = filter_input(INPUT_SERVER, 'HTTP_X_REQUESTED_WITH', 513);
# FULL_SPECIAL_CHARS
$server_request_method = filter_input(INPUT_SERVER, 'REQUEST_METHOD', 522);
$http_encoding = filter_input(INPUT_SERVER, 'HTTP_ACCEPT_ENCODING', 522);

So, anyway, by utilizing PHP's (now) inbuilt filters, we can use $_SERVER variables without too much worry.

I hope this helps someone who wanders onto this thread looking for answers.

Answer 5

Don’t forget to convert every occurrence of "$_SERVER['PHP_SELF']" into "htmlentities($_SERVER['PHP_SELF'])" throughout your script.

How to Avoid the PHP_SELF exploits http://www.html-form-guide.com/php-form/php-form-action-self.html

Answer 6

No, as anyone can change the href of a link anyway (using a tool like Firebug). Of course, make sure you do not put any sensitive data in that link.

Always be sure to correctly validate and parse user data that you receive.