Closed xzhang-ipipeline closed 2 weeks ago
Hi @xzhang-ipipeline,
thanks for reporting.
Describe the bug I suppose that "utf8toUnicode" should be able to handle full-width attacks. However, it doesn't seem that the attacks using full-width get detected, e.g. <script>alert("encoded")</script>
... To Reproduce Used below example with version 3.3.2 and didn't trigger any XSS rules.
First of all: do you think this is really a ModSecurity issue? Or the rule set?
<script>alert("encoded")</script>
Expected behavior Expect the rules 941100, 941110, 941160, 941320 to be triggered by the example
Have you tried with other rule set? Eg. with newest CRS?
With 4.6.0 I get this:
ModSecurity: Warning. detected XSS using libinjection. [file "/home/airween/src/coreruleset/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf"] [line "82"] [id "941100"] [rev ""] [msg "XSS Attack Detected via libinjection"] [data "Matched Data: XSS data found within ARGS:q: <script>alert(\x22encoded\x22)</script>"] [severity "2"] [ver "OWASP_CRS/4.6.0"] [maturity "0"] [accuracy "0"] [tag "application-multi"] [tag "language-multi"] [tag "platform-multi"] [tag "attack-xss"] [tag "xss-perf-disable"] [tag "paranoia-level/1"] [tag "OWASP_CRS"] [tag "capec/1000/152/242"] [hostname "::1"] [uri "/"] [unique_id "172624299437.964310"] [ref "v8,99t:utf8toUnicode,t:urlDecodeUni,t:htmlEntityDecode,t:jsDecode,t:cssDecode,t:removeNulls"], client: ::1, server: _, request: "GET /?q=<EF><BC><9C><EF><BD><93>....
and with many other (mentioned) rule.
Server (please complete the following information):
* ModSecurity version (and connector): v3.3.2
There is no such version. There are versions mod_security2 2.9.8 and libmodsecurity3 3.0.13.
Or may be did you want to report this issue at Coreruleset?
* WebServer: Kemp LoadMaster
As I know Kemp uses Apache + mod_security2. But you put the label [3.x] onto this issue.
Rule Set (please complete the following information):
* Running any public or commercial rule set? OWASP ModSecurity Core Rule Set * What is the version number? v3.3.2
Please try that with 4.6.0.
Btw 3.3 version has 3.3.6, you should try that too (but I don't think there is any relevant change related to this issue)
Thanks again!
Sorry, my bad. I put the ruleset version for ModSecurity version. I'm not entirely sure if it's related to ModSecurity or the core rule set or even Kemp. All the 941 rules have transformation utf8toUnicode which is supposed to take care of full-width.
And I can see at least rule 941100 worked for you. So I might have to ask Kemp what version of ModSecurity is used.
Thanks for looking at this. Appreciate it.
Actually the browser encodes the text and send. @airween can you please try below to see if it triggers any rules?
<script>alert("encoded")</script>
Actually the browser encodes the text and send. @airween can you please try below to see if it triggers any rules?
<script>alert("encoded")</script>
@xzhang-ipipeline sorry, could you send me a curl
example how should I check?
Here it is:
curl -X POST -i --data '<script>alert("encoded")</script>' -H "x-format-output: txt-matched-rules" https://sandbox.coreruleset.org/
Thanks - please explain which rule you expect to trigger against above request?
Expect below rules to be triggered
941100 941110 941160 941320
Thanks - I try to understand the concept, but sorry I don't see why should have these rules been triggered?
The payload will be interpreted as:
ARGS_NAMES:|ARGS_NAMES:#65308;|ARGS_NAMES:#65363;|ARGS_NAMES:#65347;|ARGS_NAMES:#65362;|
because the &
character is an argument separator. The argument parser splits this string along &
, then you will get these POST argument keys:
#65308;
#65363;
...
and the values are empty strings in all cases. You can imagine this request as
#65308; = ''
#65363; = ''
where the left side of =
is the key and the right side is the value.
Please fix me if I don't see something.
That's a simplified version of the example. Below probably makes more sense:
curl -X POST -i --data 'txtDescription=<script>alert("encoded")</script>' -H "x-format-output: txt-matched-rules" https://sandbox.coreruleset.org/
Once it reaches to the server and the value get decoded, it becomes: txtDescription=<script>alert("encoded")</script>
Once it reaches to the server and the value get decoded, it becomes
Sorry, decoded whit what?
You send a POST
request, and want to send a text were you replaced the characters by their HTML entities.
This is NOT a valid encoding for POST
(neither for GET
) request(s). If you want to send this text you must encode it with urlencode.
If I use urlencode (against the text you given) I get this from the Sandbox:
941100 PL1 XSS Attack Detected via libinjection
941110 PL1 XSS Filter - Category 1: Script Tag Vector
941160 PL1 NoScript XSS InjectionChecker: HTML Injection
949110 PL1 Inbound Anomaly Score Exceeded (Total Score: 15)
980170 PL1 Anomaly Scores: (Inbound Scores: blocking=15, detection=15, per_pl=15-0-0-0, threshold=5) - (Outbound Scores: blocking=0, detection=0, per_pl=0-0-0-0, threshold=4) - (SQLI=0, XSS=15, RFI=0, LFI=0, RCE=0, PHPI=0, HTTP=0, SESS=0, COMBINED_SCORE=15)
Note, that if I use htmlentities and encode that text then none of the rules triggered. But it's not a ModSecurity issue.
Thanks for looking into this @airween . I'll close the issue.
Describe the bug I suppose that "utf8toUnicode" should be able to handle full-width attacks. However, it doesn't seem that the attacks using full-width get detected, e.g. <script>alert("encoded")</script>
Logs and dumps
Nothing is shown in the log to indicate any of the XSS rules were triggered by the example.
Notice: Be careful to not leak any confidential information.
To Reproduce Used below example with version 3.3.2 and didn't trigger any XSS rules.
<script>alert("encoded")</script>
Expected behavior Expect the rules 941100, 941110, 941160, 941320 to be triggered by the example
Server (please complete the following information):
Rule Set (please complete the following information):
Additional context
Add any other context about the problem here.