ModSecurity Blog

Wouldn't it be cool if your WAF could share its data with the application it is protecting? This concept is similar to anti-SPAM SMTP apps that will add additional mime headers to emails providing the SPAM detection analysis information. The CRS is attempting to mimic this concept at the HTTP layer by adding additional request headers that provide insight into any ModSecurity events that may have triggered during processing. The advantage of this approach is that it allows a WAF to be in a detection-only mode while still providing attack data to the destination application server. The recieving app server may then inspect the WAF request headers and make a determination whether or not to process the transaction. This concept is valuable in distributed web environments and hosting architectures where a determination to block may only be appropriate at the destination app server.

This concept has actually been discussed as part of the OWASP AppSensor Project and we have added a new Detection Point for it entitled - RP2: External User Behavior

This information can be used by the application to contribute to its knowleage about a potential attacker. In some cases, the information could be detected by the application itself (e.g. XSS pattern black listing), but may be more effectively identified by the external device, or is not known to the application normally (e.g. requests for missing resources that the web server sees, but does not pass onto the application).

CONSIDERATION

The greater the knowledge a device or system has about the application, the greater confidence can be given to evidence of suspicious behaviour. Therefore, for example, attempted SQL injection detexcted by a web application firewall (WAF) might be given greater weight than information from a network firewall about the IP address.

The power of AppSensor is its accuracy and low false positive rate, and the usage of external data should be carefully assessed to ensure it does not contribute to a higher false positive rate.

EXAMPLES

Example 1: An IDS has detected suspicious activity by a particular IP address, and this is used to temporarily tighten the attack detection thresholds for requests from all users in the same IP address range.

Example 2: An application is using the ModSecurity web application firewall with the Core Rule Set, and utilises the anomaly score data passed forward in the X-WAF-Events and X-WAF-Score HTTP headers (optional rules in modsecurity_crs_49_header_tagging.conf) to adjust the level of application logging for each user.

Example 3: Information from an instance of PHPIDS suggests request data may be malicious.

@sasha
I think that is a good point, but I think that you should consider an architecture where mod_security stays in front and blocks those headers coming from outside.
Also I think Ryan assumes that between the WAF and the application is not possible to sniff and modify the traffic on the fly.

Then of course we'll need the application to be aware of the Header tagging. Which is quite ahead in the web app sec concept we daily face. :)

But I was never able to get the real benefit of WAF. If you want to provide a solid level of security, you would have to implement as many filters on the WAF/proxy like you would have to do in your secured application. Applying WAF/proxy rules is the same like fixing/enhancing your applications. Why chose the higher level of complexity and maintain another device? Especially if you use WAF as sensor only, this proves my point.

The only contradiction is that you would be able to improve flexibility and scalability because you are able to switch tasks between the components. But does this legitimate the higher level of maintenance and new potential attack vectors?

@sasha - as Stefano pointed out, the concept here is with a distributed architecture where modsecurity is running on a front-end, reverse proxy server. In this setup, we can export our anomaly score data and add it the request headers on the back-end of the connection when Apache proxies the request to the destination web server. Also as Stefano mentioned, if we see any existing WAF request header data on the front-end of the request, then we can block it as it is obviously spoofed.

@Stefano - I agree that this concept is a bit ahead of its time. Still, web applications already often inspect other request header data to make security decisions (Cookies, SessionIDs, etc...). This concept fits in perfectly with OWASP AppSensor and ESAPI.

@Marc - I understand your viewpoint. WAFs are of greatest value when organizations either don't have access to the source code (or 3rd party apps/plugins) and/or when the cost to fix the issue in the code is deemed too high from a business perspective. From a complexity standpoint, yes this does add a layer however there is a flip-side as well and that is scaled security protections. Most organizations don't have a homogenous web architecture and thus can't leverage secure code reuse. So, by externally implementing some of these security protections, you can do this regardless of web language/platform.