By:
Greg Wroblewski, Microsoft Security Engineering Center
Ryan Barnett, Trustwave SpiderLabs
Vulnerabilities in on-line services, like cross-site scripting, cross-site request forgery, or even information disclosure, are important areas of focus for the Microsoft Security Response Center (MSRC). Over the last few years Microsoft has developed a
number of tools capable of mitigating selected web specific vulnerabilities (for example,
Although the source code of ModSecurity’s IIS components is fully published and the binary building process is publicly described (see mod_security/iis/winbuild/howto.txt in
A standard MSI installer of ModSecurity for IIS 7 and later versions is available from
<a></a>
The IIS installer does not interfere with currently running web applications. This means that the installation process must be followed by an application pool restart or recycling in order to load the new module into the application pool process. For the
RC version of the module the restart/recycle step is also highly recommended each time a ModSecurity configuration file has been changed:
After successful load of the module into the application pool process a series of informational events is recorded in the application event log:
Runtime messages and notifications generated during the operational phase, both coming from the user-defined rules and system specific events or errors, are sent to the same application event log repository.
To apply a ModSecurity configuration file to a web application or a path, one has to use IIS configuration schema extension, like in the example below:
The c:\inetpub\wwwroot\test.conf config file is a regular ModSecurity configuration containing the same directives as used on the Apache web server.
The most common application of ModSecurity is a protection layer called “virtual patching” (see Resources section, [5]). Using two recent vulnerabilities as an example we would like to show how this layer can be specified in an environment with IIS server
running with ModSecurity.
attacker to send a large (typically 1MB or 4MB) POST request to the server, with tens of thousands of arguments with specially crafted names. There are at least four ways to mitigate this kind of attack:
Restrict the request body size.
Restrict the number of arguments.
Identify repetitive payloads.
Check arguments names against PoC data.
The approach of checking for the presence of repetitive payload is the most sophisticated one and it can be implemented in ModSecurity using the following chain of rules:
When this rule is loaded into an IIS server configuration and the attack is launched on the protected path, the Windows application event log will record an access denied message from ModSecurity:
At the same time the attacker will see HTTP response 403, stopping the attack before it reaches ASP.NET vulnerable component.
to trick user into clicking on a malicious URL, like the one below:
http://sharepoint/_layouts/scriptresx.ashx?culture=en‑us&name=SP.JSGrid.Res&rev=laygpE0lqaosnkB4iqx6mA%3D%3D&sections=All<script>alert(‘Hacked!!!’)</script>z
The script injected by the attacker could gain access to the entire data set available to the victim through the hacked SharePoint server.
One possible way to block this attack is a whitelist approach: let the URL with sections argument that does contain only valid characters pass through, while block all other URLs. Below is a ModSecurity rule implementing this approach for alphanumeric characters:
The rule included through ModSecurity config file into the SharePoint web.config file, generates the following event when any invalid character (indicating possible attack attempt) is discovered in the corresponding SharePoint URL:
We encourage you to download and try out the tool. If you have any feedback on your experiences with the tool, you can reach us at
The following people have contributed to the multi-platform effort of ModSecurity:
Microsoft – ModSecurity Port for IIS
Greg Wroblewski – Senior Security Developer
Suha Can – Security Researcher / Developer
Trustwave - ModSecurity
Ziv Mador – Director of Security Research
Ryan Barnett – Security Researcher Lead
Breno Pinto – ModSecurity Researcher & Developer
Open community - Security Port for Nginx
Alan Silva - Security Software Engineer at Locaweb
We would like to thank: Wade Hilmo and Nazim Lala, members of the Microsoft’s IIS team , for their support and help in solving many technical problems.