feat(942500): stronger hardening to improve PL1 protection
Hello,
This PR follows 4325. As mentioned there:
A possible solution (on PL1) to avoid relying exclusively on 942100 would be to strengthen the 942500 regex so that it captures all comments of the form /* … */, not just those specific to MySQL.
Rule 942440 does capture these types of comments, but its placement in PL2 is due to the fact that it combines multiple detections, including --[\w]-.
--[\w]- triggers erratically on simple slugs or typos, which fully justifies its position in PL2 - and, in my opinion, it might even deserve to be in PL3.
I propose to significantly strengthen the regex in rule 942500 to capture all comments of the form /.../ at PL1.
What do you think ?
Vincent
📊 Quantitative test results for language: eng, year: 2023, size: 10K, paranoia level: 1:
🚀 Quantitative testing did not detect new false positives
my spidey sense is tingling, beware false positives
None observed here on guest input - this only affects screens that handle HTML/JS/CSS as input, and even then very rarely, and I wouldn’t consider those to be false positives.
In any case, back-office interfaces are a hotspot for rule triggers, including for the vast majority of PL1 rules, so this change won’t make that situation any worse.
Thank you @touchweb-vincent.
Like @dkegel-fastly, I see a high risk of new false positives. Truth be told, the generalization of the regex at PL1 is very ambitious. But also the expansion of the target list. OK for the filename, but including UA and Referer is like asking for FPs.
Maybe splitting the PR into target expansion and a separate regex update PR would allow to discuss and decide this separately (if that is possible at all).
I encourage you to test the adjusted rule - there have been no false positives on User-Agents or Referers with this pattern for years. This pattern simply doesn’t lend itself to that.
The only issue is the HTTP Accept header — and I’ve intentionally excluded it.