Belt AND Braces: Web apps and mod_security

OK, so now you have your invincible web application. You’re done, aren’t you?

Well, not entirely. You still have a single point of failure, which is your web application, and engineers tend not to like systems with single points of failure. There are potentially lots of clever people trying to find problems in your website. It only takes one of your developers to commit a couple of lines of code like the following to put the whole site at risk of compromise:

If only someone had written a program to screen out common malicious input for webservers.

Well, they have. It’s called mod_security and it’s available for IIS or Apache – and if you don’t want to meddle with your existing setup, you can always set up apache+mod_security as a reverse proxy in front of it.

It is not a silver bullet, but it can make things very much harder for an attacker, as it will frustrate a lot of the common attacks. And of course, while they are failing to break in and refining their technique to get around such things as Web Application Firewalls (WAF), you are aware of their repeated attempts to break in because you look at your log files, don’t you?

You can import the logs into something like Splunk, or into Alienvault’s OSSIM, or you can look through them by hand – I’m not really bothered as to the mechanism, but if “sqlmap” becomes your third most popular User-Agent string, you need to be aware of the fact, and you might want to check whether those people might not know something that you don’t.

Another thing that a lot of people forget to enforce is that your webserver should not be fetching pages itself. You can write a firewall rule to deny any connections initiated outbound by your webserver, except to your B2B partners. Generally, the flow is that someone asks you for a webpage, and you supply it – any unsolicited requests to other sites, particularly for id.txt or c99.php or r57.php are bad news and they should be rejected.

So, while it is important to get the actual code correct on your webserver, it is still worthwhile implementing some sort of WAF as a screening exercise, in case one of your programmers has an off day, and also creating some sort of Intrusion Detection System, to catch a breach, or attempted breach as early as you can.

There are other WAFs out there, but I find mod_security is the easiest to trial. If you want to more detailed work, such as ensuring an XML schema is adhered to for web services, you may want to look at commercial products such as Imperva.