7

It's been a few years since I mucked around with modsecurity...

Will simply installing the package with the default rules provide enough validation to prevent any (okay, let's be honest - best we can hope for is "most") type of XSS? My assumption is no... and even if we consider only Type I - Reflected XSS.

What about the Core Rule Set? Is that XSS-proof enough?
If not, what kind of rules are missing, and what should I look to add/customize, maybe on a per-page basis? (uggh...)

Last part of the question, what about AJAX-heavy apps? How does ModSecurity, and in particular the CRS, handle AJAX requests without blocking them? I assume that hoping that it actually manages to parse out the AJAX and validate each parameter seperately would be too much to hope for...

To clarify, fixing the code to remove all XSS, including input validation and especially contextual output encoding, is of course the best way to go, and really the only long-term solution.
However, I was looking for a temporary, "quick fix", to pop something in place to protect the app for now, while they go and fix the XSS in the code, and search for more...

AviD
  • 72,138
  • 22
  • 136
  • 218

4 Answers4

8

You should review the XSS Street-Fight (with ModSecurity) Blackhat preso

It outlines the following ModSecurity mitigation strategies for XSS:

  1. Input Validation (Whitelist/Blacklist Filtering)
  2. Generic Attack Payload Detection
  3. Identifying Improper Output Handling Flaws (Dynamic Taint Propagation)
  4. Application Response Profiling (Monitoring the number of scripts/iFrames)
  5. JavaScript Sandbox Injection (ModSecurity’s Content Injection Capabilities)
Samuel Dauzon
  • 103
  • 4
Ryan Barnett
  • 146
  • 1
  • oo, I got the big man himself! :) Now that Ofer and Or are not involved, I didn't know who to turn to... So, bottom line, ModSecurity+CRS does the job, in generic cases? – AviD Apr 11 '11 at 05:48
  • Well, ModSecurity *can* help to introduce many layers to help identify both XSS attacks and locations that are vulnerable however packaging it up to work out of the box for every site is challenging. The first 4 items are in the lastest CRS in trunk. We haven't included the JS Sandbox feature yet however you can test it out here - – Ryan Barnett Apr 11 '11 at 12:44
  • http://www.modsecurity.org/demo/demo-deny-noescape.html – Ryan Barnett Apr 11 '11 at 12:45
  • @Rook: regarding W3AF's evasion plugins for ModSecurity - that was a NUL byte parsing issue from 2007 which was quickly fixed. Your larger point of bypasses/evasions is correct however and that is why you should look to tackle these issues from many different angles. – Ryan Barnett Apr 11 '11 at 12:50
7

I was going to suggest that you check out Ryan Barnett's work, but he already answered!

Data validation is not enough to prevent XSS, even if it's a pure whitelist.

The identification of improper output handling must occur on all outputs. They might be able to be fixed contextually with ModSecurity, but certainly this is the wrong place in the architecture to do it -- since if anything changes with regards to that content -- the encoding/escaping would suddenly become useless. Web content has a way of changing a lot.

The correct answer is to monitor output escaping issues with ModSecurity -- and actually remediate XSS issues elsewhere.

One of the best approaches I've heard lately is to Stop Building HTML on the Server. In particular, this would kill two birds with one stone: you could solve the problems with AJAX (e.g. DOM-based XSS) as well as stored and reflected XSS issues.

However, I strongly encourage you to check out the Encoding libraries in OWASP ESAPI and OWASP ESAPI JS. The best remediation advice comes from contextual output encoding. Remediating XSS is a lot of work, but it's worth to think about these problems as longer-lasting and with serious impact if we don't fix them now.

D.W.
  • 98,420
  • 30
  • 267
  • 572
atdre
  • 18,885
  • 6
  • 58
  • 107
  • I'm going to +1 you, even though its not really an answer to my question - but it is the CORRECT answer, unfortunately I'm dealing here with my client's constraints... Of course the long term solution is to fix the code, but I was looking for a temporary quick fix. – AviD Apr 11 '11 at 05:32
0

Mod Security is absolutely fantastic work by everyone involved. However, don't expect to just "set and forget". It took us a lot of work to fine tune the install to get rid of false positives from the core rule set.

getahobby
  • 175
  • 3
0

Probably not, but you should test it for your self. Sitewatch, Acunetix, and W3AF are all free and they will test your application for XSS. Beyond that, an attacker can build a payload for XSS specifically to bypass mod_secuirty. For instnace there are Mod_Security bypass modules for W3AF. So using a WAF like this is is not a Defense in Depth approach.

rook
  • 46,916
  • 10
  • 92
  • 181
  • The author of Sitewatch in particular references that some XSS are hard to find even when performing code-assisted penetration-tests. No scanner or tool can do the job of a bunch of expert humans. – atdre Apr 11 '11 at 17:43
  • @atdre you should always use automation to find the low hanging fruit. Then move on to more expensive methods of bug hunting. – rook Apr 11 '11 at 18:54
  • @Rook: Don't tell me what to do! I won't use automation and you can't stop me! ;) -- but seriously, it's true -- spending time and money on automation can actually be more expensive. I'm not just speaking to corner-cases. Automation should be up to the person driving the test on where and how to implement it. Pure or full automation is only useful in very rare cases -- but the infosec vendors would have you believe otherwise. – atdre Apr 11 '11 at 19:15
  • @atdre I'm sorry but I don't see how running a free service is somehow expensive. It does take about 5 minutes to setup, I'll give you that. You won't only hear this from me, run an automated tool to find low hanging fruit. Especially for xss, there are too many edge cases, you can't just use `htmlspeicalcahrs()` and expect it to be safe. After that then use time consuming tools like RIPS (very cool tool) or RATS. You shouldn't take this with a grain of salt afterall [I should know](http://www.exploit-db.com/author/?a=628). – rook Apr 11 '11 at 19:20
  • It's expensive for pen-tester to setup and it's a distraction. Then, you have to wait for the results. Who knows what the results are going to be? Probably useless! It might be more useful if it emails you when the results are ready. App scanners always crash, loop, or run into other problems. – atdre Apr 11 '11 at 19:53
  • @atdre Sitewatch doesn't crash or loop, and its on the [Google Hall of Fame](http://www.google.com/corporate/halloffame.html). – rook Apr 11 '11 at 21:43
  • 1
    @Rook: All programs have the opportunity to crash or loop. I don't care about your lists of exploits or the Google Hall of Fame. I care about reality – atdre Apr 11 '11 at 22:38