It is now fixed in GitHub repo. I opted to do this instead which simply looks for the existence of that TX variable using the & char. If it not present (meaning that the @pm rule did not find any matches), then it will initiate the skipAfter action -
SecRule &TX:PM_XSS_SCORE "@eq 0" "phase:2,id:'981018',t:none,pass,skipAfter:END_XSS_CHECK,nolog" -- Ryan Barnett On 1/18/13 11:39 AM, "Damien Wyart" <damien.wy...@gmail.com> wrote: >Hi, > >I am also annoyed by this bug in the CRS and suprised nobody responded >to the two messages explaining the bug. > >Is it plan to integrate this in 2.2.7? Or is there a need for a GitHub >pull request (even for such a trivial fix)? > >If this is not fixed upstream, some users (including me) might need to >backport this manually, this is really annoying. > >Many thanks in advance, > > >Damien > >> Hi Ryan, are you planning to add this little fix to the 2.2.7? That >>would really be great! > >> Thank you! > >> On Friday, November 9, 2012, rm4dillo D wrote: >> Hi, > >> The "base_rules/modsecurity_crs_41_xss_attacks.conf" rules file starts >>with a smart rule that checks the presence of some keywords (Ex. script >>javascript...) and depending on the result, it decides to run deeper >>rules or just skip them. The problem is that the conditional "skip" >>never works because it tests the "pm_xss_score" variable which is not >>initialized. > >> SecRule TX:PM_XSS_SCORE "@eq 0" >>"phase:2,id:'981018',t:none,pass,skipAfter:END_XSS_CHECK,nolog" > >> To fix this, I just directive this at the beginning of the file: > >> SecAction >>"phase:2,rev:'2.2.5',t:none,pass,nolog,setvar:tx.pm_xss_score=0" > >> It would be nice to fix this in the next core rule set release. >> Thank you in advance. >> Rm4dillo > ________________________________ 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
