Security research, news and guidance

Virtual patching with mod security

December 3, 2010  |  Written by Security Ninja  |   Application Security, Data Loss   |   5 Comments

Hi everyone,

As someone who is responsible for operational security I think that one of the biggest challenge I have to deal with is how to keep the systems and applications up to date with no service interruptions.

It is not only a question of having good patching polices or procedures that dictate how you have to patch after a vulnerability is found in your platform. The time required to analyse the vulnerability, develop a fix, test the fix and deploy it into production can leave a system vulnerable to attack for a period of time which might not be acceptable to the business.

In an ideal world application security vulnerabilities will be fixed by the development team following your secure development processes. The ideal world very rarely exists and there are some situations when it is not possible to patch application vulnerabilities in an acceptable time period. If you think about a public web application being vulnerable to an XSS attack and it is also critical to the business it isn’t always possible to apply a code change in the middle of the day. Even if a code change is approved we need to analyse the vulnerability, design a solution, develop the fix the, test the fix in QA, security review the code, security test the code, upload the code to pre-production, test again and if everything is still working we deploy it into production. This process will take time even if you have a highly skilled team and well defined processes and procedures.

As a person responsible for operations security I would look at alternative, temporary solutions in a situation such as the one outlined above. An alternative approach might allow us to reduce the risk of the vulnerability being exploited whilst we are waiting for a fix to be developed and deployed. Intrusion Prevention Systems and Web Application Firewalls are some examples of technologies we could use to implement a temporary fix, a “virtual patch”.

In today’s blog post I will use mod security which is a very well known open source web application firewall. I highly recommend both the project and the book published about mod security.

In this post I’m going to show a video example of an application that has a stored XSS vulnerability in a guestbook form field and how we can mitigate the problem with mod security.


In the first part of the video you can see that the application is vulnerable to XSS and once the admin user is logged in it is possible to steal the session cookie.

In the second part of the video, mod security is added to the Apache server and the attack is stopped by the server. The logs show information about the attack and how it was blocked.

Even though this is a very simple example mod security is a very powerful tool and can implement very complex rules, like filtering the responses from the server to the client for example. As I said at the beginning of the post this virtual patching approach should only be implemented as a temporary solution and/or an additional operational security layer. You should always aim to address application security issues through strong secure development processes and approaches such as the principles of secure development.


This entry was posted on December 3, 2010 at 4:31 pm and is filed under Application Security, Data Loss . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.


  1. netalien says:

    If I understood correctly, you’re talking about adding mod_security after the XSS is found in order to stop the attack while the fix is being developed, tested and deployed which is good.

    But adding mod_security is something that need to be tested as well, you need to know that the rules applied by it won’t end blocking a part of the services offered by the application which are not affected or even related to the XSS hole.

    If I’m not mistaken then, the time in testing (and possible adapting) mod_security to your application will be more affordable than the time spent waiting for the fix right?

    Also, a better approach won’t be to already have mod security in place and then, change the configuration to stop the XSS while the fix is developed and deployed?

    Just asking because of curiosity :)

  2. Security Ninja says:


    Thanks for the comment!

    I should have been clearer in the blog but I meant that utilising something like mod security “all the time” in your infrastructure can help prevent common vulnerabilities being exploited. This blog was just a quick post to show how using something like mod security can also allow you to implement virtual patches as well as providing on going protection.

    I completely agree with what you said, adding either the patch or mod security as a solution would require a large amount of testing.



  3. netalien says:

    Cool!, just wanted to know if I misunderstood what you meant ;)

  4. Abraham Aranguren says:

    I agree that having mod_security enabled with the default rules is a good idea because it helps to block many attacks that might have leaked through security testing and QA.

    That being said, I would like to point out that one thing is adding additional layers of security, like a web application firewall using the default rules. This makes the life of the attacker more difficult because they have to spend time to bypass the firewall before they even know there is a vulnerability behind. But it must be noted this method is blacklist based: mod_security is trying to identify potential attacks to block them. There are obfuscation techniques that could potentially bypass this (although the effort is much greater).

    My understanding of the concept “virtual patching”, at least performed correctly, would be a custom mod_security white list rule that would only allow the data expected by the vulnerable parameter. For example, if you have a field that is supposed to take a number you could create a rule that blocks everything that is not a number. This approach is much better than just using the mod_security core rules without customisation because a bypass is significantly harder and most likely impossible to bypass. I saw no custom rule in the video, it looked like you just enabled the core rules.

    So, the distinction I would like to make is that what you show in the video is an additional layer of security which follows the principle of “defence in depth”, making a potential attacker waste time in the web application firewall and hopefully discourage them from attacking your site but it is definitely not a virtual patch for a known vulnerability. You can borrow some time with the default rules but a virtual patch (i.e. white list web application firewall rule) is a more robust approach for this.

    I believe you knew all this but it is important to clarify this distinction.

    Other than that nice post, keep them coming!

  5. Realex_Angel says:

    Hi Abraham,

    Thanks for your comment.

    The idea of the post was to use a simple example to make it easier to follow. In this case, the default rules from mod_security had signatures to stop the generic XSS used in the example and it was not necessary to create a custom signature. However with this kind of technology, like with an IPS, you always should try to customise the rules for your application.

    Regarding the concept of virtual patching, my interpretation of virtual patching is to apply a temporary fix to a vulnerability when there is no official patch available or it is not possible to apply it quickly. For example a signature in an IPS or in a WAF that blocks the attack that can exploit the vulnerability. Of course, if you are able to and have the time to create more accurate signatures to block everything that is not in a white list, it’s going to be more secure and reliable.


Leave a comment


Look at our latest security Videos & SlideShares


Upcoming Security Events & Seminars


Check out our Podcasts & White Papers