ModSecurity Blog

NIST has released a new guide on securing Web Services. It is a pretty good read for anyone who is planning to run WS, specifically Appendix A which lists Common WS Attack categories such as:

Reconnaissance Attacks

Privilege Escalation Attacks

Attacks on Confidentiality

Attacks on Integrity

Denial of Service Attacks

Command Injection

Malicious Code Attacks

Protecting Web Services with ModSecurity

If you compile ModSecurity 2.x with XML support (with libxml2) and activate the libxml2.so file in httpd.conf, you can gain some protection for your WS traffic. While ModSecurity can not prevent every WS attack category listed above, it can certainly help to prevent a large number of the common HTTP attacks that now simply riding in the XML payloads.

XML Support in the Core Rules

Version 1.4 build 2 of the Core Rules introduced support for inspecting the the XML payloads of Web Services transactions. You can identify this by the inclusion of the XML:/* data in the variable listing. An example rule is listed below:

Since the Core Rules offers generic detection and does not tie specific attack payloads to specific parameters, the XML:/* variable is somewhat similar to the REQUEST_BODY payload in that ModSecurity will treat it as one large piece of data. This results in ModSecurity searching the entire XML payload looking for rule matches. For those ModSecurity users who are familiar with the 1.9.x branch, this is similar to the SecFilter rule processing where it performs a wider search for attacks as it does not know exactly where the input vectors are located. The side-effect is that there may be a performance hit if you WS XML payloads are large. If this is the case in your environment, they you will want to create some custom XML rules.

Custom XML Rules

ModSecurity can also be used to create custom rules for your WS application. Not only will this make the protection stronger and lowering the false positive rate, but you will also gain a performance boost when you specify full XPath locations in the variable list vs. the generic XML:/* variable that the Core Rules utilizes. We have created a use-case document entitled Securing Web Services with ModSecurity2 that will help to provide you with some examples of how to setup custom WS rules. Taking the previous Core Rule example, if we customize it for our WS application that is running at "/axis/getBalance.jws" and has one input parameter called "id", then the new rule would look something like this -

Notice the bolded portions of the ruleset where we have updated the XML variable to include a full XPath to our "id" input parameter and we also specified two xmlns actions to help ModSecurity to appropriately parse the payload.