OWASP ModSecurity Core Rule Set

Hello OWASP Leaders. I wanted to let you all know that a new version of the OWASP ModSecurity Core Rule Set (CRS) is now available (v2.0.7).

There are some interesting updates, most notably -

1) The new CSRF protection ruleset.

The ruleset uses ModSecurity's Content Injection capabilities to append an updated version of the csrf.js file from the OWASP CSRFGuard Project (http://code.google.com/p/owaspcsrfguard/source/browse/trunk/main/OWASP-CSRFGuard/src/org/owasp/csrfguard/handlers/csrf.js) to the end of the response data. ModSecurity generates the CSRF token and inserts it into the JS data and then validates it on subsequent requests.

The advantage of using ModSecurity for this is if you are running it on an Apache reverse proxy, then you add in CSRF tokens to any back-end web app regardless of the language.

A call for assistance - the csrf.js code works well however it should probably be extended to handle AJAX calles, etc... If there are any JS ninjas who want to tackle updating the JS code to perhaps add the csrf tokens using OnSubmit or something, let me know.

2) App Defect Rule - Missing HTTPOnly flags

One ruleset will identify if the HTTPOnly flag is missing when the app hands out Set-Cookie SessionIDs. It can optionally fix the issue by passing ENV data to Apache which will append the HTTPOnly flag through a ResponseHeader directive.

3) App Defect Rule - Missing Output Escaping of User-Supplied Data

This is an interesting concept where we are attempting to do some crude Dynamic Taint Propagation tracking related to XSS/Missing Output Escaping. As opposed to trying to identify and block potential XSS payloads on the inbound, we are instead focusing in on the underlying vuln - resources that don't properly track user-supplied data and encode/escape it when given back to clients.

The ruleset basically looks for inbound data that contains meta-characters that are often used in XSS attacks (<,>,/, etc...) and then it stores the entire parameter data in a temporary variable and then inspects the response body to see if the same exact payload is present. If it is, then the app is not properly escaping it. This ruleset works in limited testing but I am interested to see how it fairs once the ModSecurity community starts testing it out :)

Please let me know if anyone has any questions, comments or would like to help out with future

CRS efforts.

Cheers.

--

Ryan C. Barnett

WASC Web Hacking Incident Database Project Leader

WASC Distributed Open Proxy Honeypot Project Leader

OWASP ModSecurity Core Rule Set Project Leader

http://tacticalwebappsec.blogspot.com