You are currently viewing What is security problem with using $_REQUEST.

What is security problem with using $_REQUEST.

From the couple of weeks I was confused that whether the usage of $_REQUEST has security problems or not, I had read many books for it and finally got a very descriptive article, here it is shared with you.
by Christopher Nadeau

 

Reference: http://devlog.info/2010/02/04/why-php-request-array-is-dangerous/

Why PHP’s $_REQUEST is dangerous

PHP offers a convenience superglobal called $_REQUEST that coalesces input from a number of sources into one easy to use array. A common thought amongst PHP developers is that you should avoid the use of $_REQUEST — but do you actually know why?

The prevailing misconception seems to be that having GET and POST variables mixed together is insecure. While this is true under some specific circumstances — it isn’t the main reason why $_REQUEST is insecure. In fact, combining GET and POST data is often a very useful feature. In many cases you don’t really care if a variable comes from GET or POST and so using $_REQUEST in those situations can help reduce the verbosity of your code while increasing flexibility.

The real problem is that COOKIE data is also mixed into $_REQUEST. The implications of this may not be readily apparent until you start thinking like a malicious user. Any cookie ever set on a users machine will always override any GET or POST data — creating “sticky” variable data.

For instance, imagine if your application uses “action=” or “do=” switches to control page commands. If an attacker some how managed to set a cookie — perhaps through some Javascript injection — he could set a cookie named “action” and give it the value “logout.” Any users that fell victim to the cookie set would never be able to use your application because “action” would be permanently set to “logout.

“So to sum it up:

Question: Why is $_REQUEST insecure?
Answer: Because it combines COOKIE as well as GET and POST, and the COOKIE data always takes precedence — creating the possibility for dangerous “sticky” variables.

Solutions

If you’re already using PHP 5.3, then you can edit your php.ini and check the request_order variable — make sure ‘C’ removed. This ‘C’ is removed by default, but if you use a shared host it might’ve been put back for backwards-compatibility. Make sure to check!

Otherwise, you can easily just create your own $_REQUEST array by merging $_GET and $_POST manually as part of your global initialization routines.

PHP:

  1. $_REQUEST = array_merge($_GET, $_POST);

And finally, best practice is to abstract your input reading out  so you can define yourself exactly how variables are read and from where.