Modsecurity vs. PHP

Tuesday, February 6. 2007

There is a very funny posting at the modsecurity blog from yesterday that speaks a bit about the combination PHP and modsecurity. Basically the entry tries to excuse the fact that most of the modsecurity rules that are in use today to protect against known vulnerabilites can be bypassed easily by simple things like adding spaces infront of the variable name.

It is quite amusing that the author blames the fact that web application firewalls parse the HTTP request in a different way than the installed application/script language (and therefore always contain bypass holes by design) onto the applications and languages. He especially blames PHP because it is so userfriendly when it comes to variable names.

I can understand that Ivan tries to defend his product. But fact is all webapplications/script languages have their own rules how they parse HTTP requests. modsecurity (and most probably other commerical web application firewalls) matches some of these understandings of HTTP partially but it does not match a single language 100% and therefore it will NEVER be secure. It is not feasible to have one parser that works on all languages because there are too many differences between the HTTP parsers.

Oh yeah... And I see no reason to especially blame PHP when a simple trick exists that works with many languages and allows getting a bunch of attacks through all modsecurity rules...

Posted by Stefan Esser in PHP, Security at 13:34

Comments (7)

Link to this post

Comments

Display comments as (Linear | Threaded)

#1 Jason Frisvold wrote (Link) ()

I've been looking a lot at adding additional security to both Apache and PHP lately. Suhosin is on the list as well as mod_security and mod_evasive. I'm just starting to look deeply into these and I haven't had a chance to really test them out yet.

If what I read in this entry is correct, it seems that mod_security doesn't actually do much to prevent attacks because of the way it parses the requests? Am I understanding that?

posted on Tuesday, February 6. 2007

#2 Stefan Esser wrote (Link) ()

mod_security splits query string, cookies, post data in the way it believes is correct (e.g. how the RFC defines it).

In reality however mod_python, perl cgis, ruby, php, ... all have their own querystring, cookie and postdata parsers. That do not follow the RFC (for whatever reasons).

Therefore whenever mod_security parses something the webapplication below might parse it in a completely different way and therefore mod_security might not see the same variables. And therefore it is logical that filters will miss these variables.

Because of this the modsecurity (and other WAF) design is flawed in a way that cannot be fixed 100%. (Unless you write different parsers for different languages).

posted on Tuesday, February 6. 2007

#3 Stefan wrote (Link) ()

Without knowledge about the application that one wants to protect, mod_security can help to filter or rejct requests, thats all. I see mod_security as a complement to Hardend PHP (still have to take an indepth look into Suhosin) to reject malformed requests before these requests traverse to the application, there are many options within PHP to secure a setup, a good start is a secure php.ini, for example:
- disable the Fopen Wrapper, allow_url_fopen = Off
- use disable_classes and disable_functions like ini_alter, ini_get_all, ini_get, ini_restore, ini_set, php_get_tmpdir, php_ini_scanned_files, php_logo_guid, php_uname, phpcredits, phpinfo, phpversion, putenv, restore_include_path, set_include_path, set_time_limit, version_compare, zend_logo_guid, zend_version, show_source, system, shell_exec, passthru, exec, proc_open, time_limit, version_compare, zend_logo_guid, zend_version, show_source, system, shell_exec, passthru, exec, proc_open etc. etc.
- set register_globals = off
- set log_errors = on, error_reporting and error_log
- use open_basedir and include_path
- use safe_mode if possible

The setup of mod_security, php and Apache depends much more on what you like to run on your server and how you like to run your scripts. Without an indepth review of the php-code mod_security can't do that much for you as a secure php.ini or proper input sanity checks, but mod_security is a good first line of defense to reject malformed requests.

posted on Tuesday, February 6. 2007

#3.1 Stefan Esser wrote (Link) ()

Well,

mod_security might be good to stop known worms.

A skilled attacker will however be able to get his payload through mod_security without triggering the rules.

And this is possible in PHP, PERL, PYTHON, ...

posted on Tuesday, February 6. 2007

#4 unixfool ()

I don't agree with most of what I've read here so far. All are valid points but I'm pretty sure that any security expert worth his salt isn't going to rely on ONLY modsecurity to firewall unwanted traffic. Security works best in layers. I run modsecurity on my server (which happens to run Apache), but I also run Snort on a dedicated interface and a gateway firewall, amongst other things.

This combination has been running for quite awhile, so I see any and everything hitting my server and have 3 different logs to conduct my security analysis (Snort logs, FW logs, and modsecurity audit logs). I can instantly see when one of these tools needs to be tuned (too noisy or not noisy enough). It also helps to be able to check the logs against each other to ensure each are working as configured.

It also seems that everyone is forgetting that in order to dodge modsecurity, a skilled attacker has to know that modsecurity is being run on that server. He also would probably have to know or suspect what types of rules the modsecurity install is using. He would also have to factor in that someone may be using Snort to augment modsecurity and that snort-inline could block something that modsecurity didn't...at the very least, Snort would log the event if it isn't configured to block hostile traffic destined to the webserver.

I'm using Snort, modsecurity and FWs such as Iptables/PF as examples, but there are MANY other tools available to augment a WAF. What you guys are saying could be applied to ANY piece of software...

posted on Thursday, February 22. 2007

#4.1 Stefan Esser wrote (Link) ()

Sorry but it is not true that someone needs to know how mod_security is setup.

Anyone who crafts his own HTTP requests can create it in a way that mod_security does understand it wrong and it will therefore not trigger ANY rule. And therefore your extra line of defense is quite THIN.

And because these are perfectly valid HTTP requests I seriously doubt they will trigger any of your SNORT or whatever rules.

And your point about having to know that modsecurity is used on a server... I don't need to know. If I send my HTTP request ist will be parsed correctly by PHP (PERL,...) no matter if mod_security is installed or not.

And you do not need to be skilled. You just need to understand C and read how mod_security parses a request.

posted on Thursday, February 22. 2007

#4.1.1 kostas ()

| And you do not need to be skilled. You just need to understand C
| and read how mod_security parses a request.

Well, that's skills too, init?

posted on Monday, October 29. 2007

Add Comment

Name:

Email:

Homepage:

In reply to:

Comment:
Standard emoticons like :-) and ;-) are converted to images.

Remember Information? Subscribe to this entry
Submitted comments will be subject to moderation before being displayed.

Calendar