-
Notifications
You must be signed in to change notification settings - Fork 728
Rule 941310: False positive #1645
Comments
Sorry for the inconvenience. However, I can't reproduce your finding, so I'm closing this for now. However, I suggest you reproduce this yourself with curl and reopen this issue together with the exact curl call. Thanks for working against 3.2.0. Using the latest version helps us with our work. |
@dune73: I'm sorry we use CRS version 3.1.0. I was distracted by [ver "OWASP_CRS/3.2.0"] in the error log. Anyway i can trigger the rule with this curl request:
|
Negative. Please provide your alert message. |
[Wed Dec 04 14:57:22.277027 2019] [:error] [pid 8562:tid 140488478672640] [client 11.22.33.44:55097] [client 11.22.33.44] ModSecurity: Warning. Pattern match "\\xbc[^\\\\xbe>][\\xbe>]|<[^\\\\xbe]\\xbe" at ARGS:test. [file "/etc/modsecurity/modsecurity.d/owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "646"] [id "941310"] [msg "US-ASCII Malformed Encoding XSS Filter - Attack Detected."] [data "Matched Data: \xbcge > found within ARGS:test: de_matten & sitzbez\xc3\xbcge > fu\xc3\x9fmatten_mt"] [severity "CRITICAL"] [ver "OWASP_CRS/3.2.0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-tomcat"] [tag "attack-xss"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "OWASP_CRS/WEB_ATTACK/XSS"] [tag "WASCTC/WASC-8"] [tag "WASCTC/WASC-22"] [tag "OWASP_TOP_10/A3"] [tag "OWASP_AppSensor/IE1"] [tag "CAPEC-242"] [hostname "xxxxxx"] [uri "/"] [unique_id "Xee7QnjhHkR1Cr9VH@B4igAAAAE"] |
This is unrelated but which paranoia level are you using? |
Level 1 (default) |
This is very odd. I can't reproduce. @fgsch: Can you get this rule to trigger on said payload? Otherwise, it may be worth to upgrade to Apache and ModSec to 2.4.41 / 2.9.3. |
I haven't tried but I recognise the rule and based on the matched data I see the issue. |
Totally so. I would not be surprised to see an FP here. But I can't seem to reproduce despite the welcome curl call. |
The problem is present on 3.3/dev. There was a change to that particular rule and that change introduced a couple of problems. We're looking into it. |
|
I figured out how the evasion targeted by rule 941310 works. Look at the following UTF-8 string: The bit sequence for the UTF-8 character UTF-8: UTF-8: What I'm not sure about is what happens to the |
Sorry to be late at the party. Is this a follow up from the original report or some other string matching? Also, can you elaborate on:
|
Yes this is a follow up to the original. He failed to mention that he was using rules from 3.3/dev. The regular expression of rule 941310 was modified in aa2794a. The string with the match is This is the regular expression in 3.3/dev: Thanks for looking at this. |
Results from the CRS project chat on March 2, 2020: We appreciate @theseion working on this. Thanks in advance! |
I have spent few days trying to figure out why ModSecurity config: CRS version: 3.3/dev (latest available) I also get lots (I mean really lot) of sqli-attack false-positives on forms where people fill their information in russian or latvian languages. It's because CRS does not do proper unicode decoding. My test results: Simplified version of rule
String:
String:
String:
Now add
String:
String:
String:
|
Thanks for that detailed report. My gut tells me that this is probably a separate issue. As I've described above, rule 941310 is there to guard against exploiting an encoding mismatch. I think (without having really looked at it) that what your change does is it modifies the bytes in the request (into Unicode) so that the rule no longer matches. That, however, only goes for the rule. The attack would still be successful because the content is only transformed for the evaluation of the rule, the actual content of the request remains the same. Therefore, when the response is being delivered, nothing will have changed. So, while your issue may be real, it's likely not related to this issue. Or, if it is, then changing the encoding of the request body is not the way to go. |
My intension is not to skip this rule with real attempt to exploit site with |
Firstly, yes, Unicode characters are a known problem for the CRS in general. Secondly, we need to fix rule 941310 in such a way that it only triggers when it matters, e.g. when coupled with I think you should open a separate issue for your suggestion to use |
Type of Issue
Incorrect blocking (false positive)
Description
This innocent german text triggered rule 941310
DE_Matten & Sitzbezüge > Fußmatten_MT
Audit Logs / Triggered Rule Numbers
Matched Data: \xbcge > found within ARGS:*********: de_matten & sitzbez\xc3\xbcge > fu\xc3\x9fmatten_mt
Your Environment
CRS version: 3.1.0
ModSec version: 2.9.2-1
Apache/2.4.29
Confirmation
[x] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.
The text was updated successfully, but these errors were encountered: