Hello Jay, Thank you for your report. This is an interesting case.
Your rule 981247 is mapped to 942360 in the upcoming CRS 3.0 release. And despite being updated slightly, the rule triggers on your request. It's quite a crazy request, I dare say. The issue is of course the parameter term=Happy%20Valley%20[DVD%20videorecording]%20/%20a%20Red%20Productions%20Production%20for%20BBC%20;%20written%20&%20created%20by%20Sally%20Wainwright%20;%20producer,%20Karen%20Lewis%20;%20directed%20by%20Sally%20Wainwright,%20Euros%20Lyn,%20Tim%20Fywell. That is term=Happy Valley [DVD videorecording] / a Red Productions Production for BBC ; written & created by Sally Wainwright ; producer, Karen Lewis ; directed by Sally Wainwright, Euros Lyn, Tim Fywell. As you can see, there is a & in that parameter. Apache splits up the argument. Outside of term, there is thus an argument named: created by Sally Wainwright... Note the initial space. This is obviously dynamic content and your client would be well-advised to encode the ampersand as well. The regex attempts to discover create and created I think this is correct and I do not think the regex should be altered. I understand you do not want to disable the rule altogether. So here is a proposal: Why don't you disable the rule for all ARGS_NAMES starting with a space character? Regex selection of ARGS names allows for this. That way you are safe the next time somebody enters a term like this. (As long as they accompany the ampersand with a space character.) Hope this helps, Christian -- Productivity is less about time management than it is about mind management. -- David Kadavy _______________________________________________ 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
