On 6/27/13 7:31 AM, "Bremgartner, Lucas"
<lucas.bremgart...@united-security-providers.ch> wrote:
>Hi all,
>
>I am currently looking at the performance of some rules in the OWASP CRS,
>especially the block "XSS Filters form IE"
>(modsecurity_crs_41_xss_attacks.conf), and I would like to have your
>opinion to the following two proposals:
>
>1. Remove rules with ID 973345 and 973346
>The two rules 973345 and 973346 are matching html-encoding-variants of
>"vbscript:" and "javascript:". Both rules are using the transformation
>functions t:htmlEntityDecode and t:compressWhiteSpace. If I understand
>these transformation functions correctly, then they are redundant to the
>regular expression (e.g. transformation from "& #x06A;" to "j" is already
>done by t:htmlEntityDecode). If this is correct, then these rules are not
>needed because they are already covered by the block beginning with rule
>981136. These rules are operating in the same phase and on the same
>targets.
>Did I miss something?
>
>2. Rule Pre-Filtering
>Most of the remaining rules (except the last 3 rules: 973316, 973325,
>973319 and of course rules from proposal 1) are beginning with one of the
>following characters: < " '
>Therefore I propose to pre-filter the whole "XSS Filters from IE" rule
>block (except the last 3 rules: 973316, 973325, 973319) with a rule like:
>
>SecRule
>REQUEST_COOKIES|!REQUEST_COOKIES:/__utm/|REQUEST_COOKIES_NAMES|ARGS_NAMES|
>ARGS|XML:/* "<|\"|\'" \
>"phase:2,id:'10000',rev:'2',ver:'OWASP_CRS/2.2.7',maturity:'8',accuracy:'8
>',t:none,t:htmlEntityDecode,t:compressWhiteSpace,pass,nolog,setvar:tx.pm_x
>ss_filter_score=+%{tx.critical_anomaly_score}"
>SecRule &TX:PM_XSS_FILTER_SCORE "@eq 0"
>"phase:2,id:'10001',t:none,pass,skipAfter:END_XSS_FILTER_CHECK,nolog"
>...
>SecMarker END_XSS_FILTER_CHECK
>
>
>With these two changes I measured a noticeable performance improvement of
>15 - 25% (depending on parameter size and parameter count) in my test
>setup with the whole CRS (base rules) activated.
>
>Feedbacks and suggestions are welcome.
>
>Regards,
>Lucas Bremgartner
Lucas,
You bring up a good point - rule detection overlap. The XSS rules have
not been properly vetted and maintained over the years and instead have
simply had new rules thrown on top. We are in the process of working on
the new CRS v3.0.0 and one of the key items is to review/update all rule
groups including XSS. We will take a more systematic approach to our
rules for coverage and performance.
It is worth noting that I will be giving a joint talk with Greg Wroblewski
of Microsoft Security Research and Defense team at Blackhat USA talking
about real-world XSS attacks and defense -
http://www.blackhat.com/us-13/briefings.html#Wroblewski. As part of this
research - Greg is developing an XSS detection module. We will be
including this with ModSecurity as a new operator @detectXSS to help with
both detection and performance.
Thanks,
Ryan
________________________________
This transmission may contain information that is privileged, confidential,
and/or exempt from disclosure under applicable law. If you are not the intended
recipient, you are hereby notified that any disclosure, copying, distribution,
or use of the information contained herein (including any reliance thereon) is
STRICTLY PROHIBITED. If you received this transmission in error, please
immediately contact the sender and destroy the material in its entirety,
whether in electronic or hard copy format.
_______________________________________________
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
