PHP: Preventing register_global problems

Nowadays it is widely accepted that using the register_globals feature of PHP leads to security problems, but it wasn't always like this (if you don't know what this feature is then you are probably not using it; but, hey, read on the discussion is informative). In fact, the register_globals feature was turned on by default until version 4.2.0. As a result of that, many applications that exist depend on this feature (for more details have a look at http://www.php.net/register_globals).

If you can choose, it is better to refactor and rewrite the code to not use this feature. But if you cannot afford to do that for some reason or another, you can use mod_security to protect an application from a known vulnerability. Problematic bits of code usually look like this:

<?php

// this is the beginning of the page

if ($authorised) {
    // do something protected

}

// the rest of the page here

?>

And the attacker would take advantage of this simply by adding an additional parameter to the URL. For example, http://www.modsecurity.org/examples/test.php?authorised=1.

Rejecting all requests that explicitly supply the parameter in question will be sufficient to protect the application from all attackers:

<Location "/vulnerable-application/">
    SecFilterSelective ARG_authorised "!^$"

</Location>

The filter above rejects all requests where the variable "authorised" is not empty. You can also see that we've added the <Location>...</Location> directives to limit filter only to those parts of the web server that really need it.