ModSecurity 2.0 hits the streets

How can ModSecurity be used to stop attacks?

Ivan Ristic: I think we first need to cover the difference between a positive security model and a negative security model. With a negative security model you are trying to figure out if there is something potentially dangerous in the traffic. This is typically how network intrusion systems work. This approach is easy to start working with but it's fairly difficult to design a foolproof rule set. Negative security rules can be written for generic web application attacks and also for known problems and exploits.

The positive security model is deployed when you only ensure the incoming data is safe to use, which is a much easier task than trying to detect bad stuff. For example, if you have a variable "userid" and it's an integer then you only need to have a rule that ensures the contents of the variable is always an integer. While more secure, the positive security model is also more difficult to deploy because it needs to be custom configured to the specific application being protected.

Another challenge lies in the fact that a positive security model is actually a duplication of the application business logic. Hence whenever the application changes the model must be updated. Some web application firewalls deal with these issues by learning the traffic and creating the positive model automatically.

ModSecurity supports both security models but it does not provide any learning facilities just yet.

What can we do to filter AJAX or AFLAX applications?

Ivan Ristic: From one point of view, AJAX applications are no different from your "normal" web applications. In both cases we have client devices (typically browsers) communicating with servers via HTTP. This means that most negative-security approaches used by web application firewalls continue to work. Rules and signatures designed to detect (and prevent) common web application attacks (SQL injection, cross-site scripting, and so on) will continue to work.

But there is a significant challenge involved with using web application firewalls to protect AJAX applications where the communication between clients and servers take place over a custom protocol transported inside HTTP. Browsers can use only two types of encoding to transport parameters: application/x-www-form-urlencoded and multipart/form-data. The competitive advantage of web application firewalls comes from the fact they understand these encoding and thus can drill into individual parameters.

There are some initial challenges with protecting these AJAX applications. Since they are implemented in JavaScript, developers are free to use their own custom encodings and many do. Although this is somewhat convenient for developers, it makes the job of web application firewalls more difficult. Since WAFs no longer understand the communication protocol, the best they can do is treat the entire data stream as text. While the negative security model is probably going to continue to work, the rate of false positives is increased.

However, I think the situation is going to improve soon. AJAX applications are just starting to be deployed so there is a lot of variety. Eventually most developers will want to use well-established AJAX libraries for their applications. They will in turn use communication protocols that are either documented or can be reverse-engineered, and web application firewalls will be able to more accurately learn the application's behavior.

What type of protection can we create to fight SQL injection attacks?

Ivan Ristic: In many cases, web application firewalls prevent SQL injection attacks but the protection is not always foolproof. Since SQL injection is a technique and not a specific attack, there are many ways of performing a SQL injection. It is possible to write a very good rule set for protection but it's not possible to guarantee that it will work 100 per cent.

The best solution is combining a positive security model of the application with the negative security of rule sets. The positive security can significantly reduce the possible false positives with SQL injection attacks and provide the best protection, since SQL injections are not normally part of acceptable application behavior.

Sometimes we hear about a bug in an application (perhaps closed-source) that we still have to run in production while we wait for a patch. Could we use ModSecurity to patch its I/O in the meantime?

Ivan Ristic: That's a very good question. External patching (also called "just-in-time patching" and "virtual patching") is one of the biggest advantages of web application firewalls. Since WAFs can intercept requests, check whether they are safe or not and simply drop offending requests, they are the easiest way to patch a known vulnerability in a web application.

Fixing vulnerabilities in web application always requires time. Organisations rarely have access to an application's source code and are at the vendor's mercy while waiting for a patch. Even if they have access to the code, implementing a patch in development takes time.

So what we have is a window of opportunity for the attacker to exploit. The beauty of web application firewalls is that they can fix this problem externally. A fix for a specific vulnerability is usually very easy to design. In most cases it can be done in less than 15 minutes. The end result is that the organisation is back in control of their fate and the risk is significantly reduced.

Recently we have been reading about a lot of exploits against browsers. Could we use ModSecurity to filter the data our webserver is sending to them?

Ivan Ristic: ModSecurity provides facilities to intercept outgoing responses and analyse them. Accessing the response status code and headers is trivial, as is access to the raw response body. But it's sometimes difficult to make sense of the response body as it is a mixture of HTML, CSS, and JavaScript, but ModSecurity treats it as one large piece of text.

I do expect ModSecurity to (optionally) start parsing response bodies some time next year. I experimented with that last year (I made efforts to restrict JavaScript invocation and placement) but none of that made it into the official development branch.

Ultimately, however, client-side security is a problem that can only be partially addressed on the server side. There are issues of trust that are not technical problems.

This article originally appeared in Security Focus.

Copyright © 2006, SecurityFocus

Federico Biancuzzi is freelancer. In addition to SecurityFocus he also writes for ONLamp, LinuxDevCenter, and NewsForge.