robertrambo wrote on Thursday, March 07, 2013:
Just found this
PHP ->http://www.modsecurity.org/documentation/modsecurity-apache/1.9.3/html-multipage/08-miscellaneous.html
PHP peculiarities
When writing ModSecurity rules that are meant to protect PHP applications one needs to have a list of PHP peculiarities in mind. It is often easy to design a rule that works when you are attacking yourself in one way but completely miss an attack variant. Below is a list of things I am aware about:
When the register_globals is set to On request parameters become global variables. (In PHP 4.x it is even possible to override the GLOBALS array).
Cookies are treated as request parameters.
Whitespace at the beginning of parameters is ignored.
The remaining whitespace (in parameter names) is converted to underscores.
The order in which parameters are taken from the request and the environment is EGPCS (environment, get, post, cookies, built-in variables). This means that a POST parameter will overwrite the parameters transported on the request line (in QUERY_STRING).
When the magic_quotes_gpc is set to On PHP will use backslash to escape the following characters: single quote, double quote, backslash, and NULL.
If magic_quotes_sybase is set to On only the single quote will be escaped using another single quote. In this case the magic_quotes_gpc setting becomes irrelevant.
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 ModSecurity 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 “!^$”
SecFilterSelective COOKIE_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> container tag to limit filter only to those parts of the web server that really need it.