Those are exact help I am looking for from ModSec community... identify limitations, weaknesses and possibly improve comprehension…
* "1'st: how would you deal with JS embeded in JSON, with HTML with events embedded in JS and/or JSON and/or XML?" First I don't pretend to be Web2.0 expert. With DOM traversing and static analysis technique like inline-code-finder, detecting JS embedded in events and style should not be too hard. https://chrome.google.com/webstore/detail/inline-code-finder/lfllandeffkmadbndfckhdbkekdfahom#detail/inline-code-finder/lfllandeffkmadbndfckhdbkekdfahom If I understood correctly, JS in JSON, XML or custom data format are content cannot not directly be executed by browser without having JS to fetch and call eval(), correct? If so, you are right, I agree that static inline-JS parsing/removing will not detect code loaded at run-time, however...we rely on CSP *unsafe-eval* and *report-uri* directives for browsers to report and submit policy violation to server, in those cases, admin can choose to manually fix or making exemptions manually or automatically. * To your 2nd point: "2'nd: if all the learned rules are configured, how do we get rid of old rules?" Previously stored metadata(configuration) should be *ALWAYS* refreshed only when sees request from trusted source for two reasons: making sure traffic under analyzing are normal traffic; preventing metadata from poisoning by attackers. Note: so called "Learning-mode" is different than conventional one, it can be set to always-On, using it whenever web apps change partially or entirely. Realistically, Even CSP 1.0 is not silver bullet, it leaves .innerHTML, .outHTML etc. unprotected, where JS can also be loaded at run-time. If a XSS defense can be *applied generically and safely*, majority use cases say 60% of legacy Webapps regardless of backend technologies are covered, will you agree that is worth of exploring? Thanks, R.S -----Original Message----- From: Achim [mailto:ac...@owasp.org] Sent: September-12-13 3:23 PM To: Rolling Stone Cc: owasp-modsecurity-core-rule-set@lists.owasp.org Subject: Re: [Owasp-modsecurity-core-rule-set] XSS/CSP brain storm Am 12.09.2013 16:54, schrieb Rolling Stone: > In "learning mode", creating Lua script to: Hmm, "learning mode" is WAF sales man's magic pitch. However it would be a good technique if it works. > 1- Intercept and scan response data, parses HTML and identify inline JS > and JS embedded in HTML events. 1'st: how would you deal with JS embeded in JSON, with HTML with events embedded in JS and/or JSON and/or XML? What will be with other formats like DWR, GWT? And then there are obfuscated scripts, or packed, etc.. 2'nd: if all the learned rules are configured, how do we get rid of old rules? (I guess rapid web developing is faster than "learning mode":) These are not ModSecurity or CRS problems, and can be found in any other WAF with "learning mode" too. Sorry for asking questions instead of providing solutions. Parsing and detecting JS correctly in modern web apps is an infinite job. Achim
_______________________________________________ Owasp-modsecurity-core-rule-set mailing list Owasp-modsecurity-core-rule-set@lists.owasp.org https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
