$_REQUEST Variable Fixation

===================================
$_REQUEST Variable Fixation
===================================

The issue described here is one that also affects register_globals, but unlike register_globals there are no plans to remove $_REQUEST. This issue is not an exploit in itself, but is one that developers should be aware of nonetheless.

=============
Background
=============

The issue with $_REQUEST is not some fault, but it is an issue it has by virtue of what it attempts to do. $_REQUEST is populated from the same sources as the superglobal arrays defined in the php.ini setting variables_order, here is php.net's explanation of what it affects:

    Set the order of the EGPCS (Environment, GET, POST, Cookie, Server) variable parsing. The default setting of this directive is "EGPCS". Setting this to "GP", for example, will cause PHP to completely ignore environment variables, cookies and server variables, and to overwrite any GET method variables with POST-method variables of the same name.

In the default setting (EGPCS) $_REQUEST is first populated with the data of $_ENV, and then with $_GET, and if there are any keys which are the same the keys already in $_REQUEST are overriden with those in $_GET, and then the process is repeated for $_POST, $_COOKIE and $_SERVER.

=============
The Issue
=============

The issue is that if an attacker is able to set a cookie with the same key as say a form element or GET variable, then the script will act on the value in the cookie untill it is removed.

Now, what actual applications can this have you ask? Well, imagine someone finds an XSS flaw in an otherwise completely secure application, where even if you obtain the session ID via this XSS hole you won't be able to do much because only one session can be active at a time, and the session id gets regenerated on every page, and the session is also bound to the user's IP, so even if you have the cookie data there isn't much you can do, and the users of the target application are generally careful enough to only enter their password in the proper place (so using the XSS hole to create a username/password form would be out of the question).
Now if this application were lets say, a bank's site, and they used $_REQUEST for getting data from the user, and the attacker then set a cookie with the key the same as the key of the field where the user enters the bank account ID where to transfer money, and sets the cookie's value to an account number which corresponds to an account under the attacker's control.

Another situation where this could be employed would be when a site uses $_REQUEST to get a new password from a user when allowing users to change their password, and you can set a cookie to make the application set a password of your liking.

=============
Conclusion
=============
While this is an interesting idea in my view, it is probably one of low severity, and its actual applications would be limited, so while its nothing to start auditing your code over it would be wise to either edit the variables_order directive to remove cookies and server variables, and maybe even environment variables, because there is only a very limited need for applications which can support input through many different methods (i.e. $_POST, $_GET, $_COOKIE, $_ENV, $SERVER), and it would be wise to reconsider your need for it, but if you decide you do need it then there is no real reason not to, though it is an issue you should be aware of.


   - kuza55