Signing JS to Defend against XSS using ModSecurity

blog.modsecurity.org

2 points·grepular··4 comments

I'm not a fan of this approach. XSS attacks tend to involve attackers coercing servers into generating JS that act against the server's interests; since the server is signing the JS, the fundamental weakness remains. Moreover, by disabling inline scripts, this tool forces dynamic JS behavior to be factored into bona fide dynamic Javascript files, and actual JS is an even harder quoting domain to deal with than the HTML DOM.

We are already moving towards a world where XSS is largely a solved problem: where servers can do content-aware neutralization of all content by default. Rails 3 is already getting close. Over the long term, this is how we're probably going to deal with the XSS problem.

I think you misunderstand the described approach. The server isn't dynamically generating javascript, nor is it dynamically signing it.

ACS doesn't inherently do that, but it's a consequence of the ACS design that the server will do that.

(Obviously, the server is always generating dynamic-SOMETHING).

Thomas would you mind expounding a bit or posting a link about the 'content-aware neutralization' approach to solving XSS? I know that Rails 3 HTML-encodes all output by default, but how would this approach fix XSS vulnerabilities using pure Javascript payloads rather than the typical approach of embedding JS in a <script> or another HTML tag?

Reply on news.ycombinator.com