owasp-modsecurity / ModSecurity

ModSecurity is an open source, cross platform web application firewall (WAF) engine for Apache, IIS and Nginx. It has a robust event-based programming language which provides protection from a range of attacks against web applications and allows for HTTP traffic monitoring, logging and real-time analysis.
https://www.modsecurity.org
Apache License 2.0
8.22k stars 1.6k forks source link

Full-width XSS attacks are not being detected #3258

Closed xzhang-ipipeline closed 2 weeks ago

xzhang-ipipeline commented 1 month ago

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.

airween commented 1 month 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!

xzhang-ipipeline commented 1 month ago

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.

xzhang-ipipeline commented 1 month ago

Actually the browser encodes the text and send. @airween can you please try below to see if it triggers any rules?

&#65308;&#65363;&#65347;&#65362;&#65353;&#65360;&#65364;&#65310;&#65345;&#65356;&#65349;&#65362;&#65364;&#65288;&#65282;&#65349;&#65358;&#65347;&#65359;&#65348;&#65349;&#65348;&#65282;&#65289;&#65308;&#65295;&#65363;&#65347;&#65362;&#65353;&#65360;&#65364;&#65310;

airween commented 3 weeks ago

Actually the browser encodes the text and send. @airween can you please try below to see if it triggers any rules?

&#65308;&#65363;&#65347;&#65362;&#65353;&#65360;&#65364;&#65310;&#65345;&#65356;&#65349;&#65362;&#65364;&#65288;&#65282;&#65349;&#65358;&#65347;&#65359;&#65348;&#65349;&#65348;&#65282;&#65289;&#65308;&#65295;&#65363;&#65347;&#65362;&#65353;&#65360;&#65364;&#65310;

@xzhang-ipipeline sorry, could you send me a curl example how should I check?

xzhang-ipipeline commented 3 weeks ago

Here it is:

curl -X POST -i --data '&#65308;&#65363;&#65347;&#65362;&#65353;&#65360;&#65364;&#65310;&#65345;&#65356;&#65349;&#65362;&#65364;&#65288;&#65282;&#65349;&#65358;&#65347;&#65359;&#65348;&#65349;&#65348;&#65282;&#65289;&#65308;&#65295;&#65363;&#65347;&#65362;&#65353;&#65360;&#65364;&#65310;' -H "x-format-output: txt-matched-rules" https://sandbox.coreruleset.org/

airween commented 2 weeks ago

Thanks - please explain which rule you expect to trigger against above request?

xzhang-ipipeline commented 2 weeks ago

Expect below rules to be triggered

941100 941110 941160 941320

airween commented 2 weeks ago

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.

xzhang-ipipeline commented 2 weeks ago

That's a simplified version of the example. Below probably makes more sense:

curl -X POST -i --data 'txtDescription=&#65308;&#65363;&#65347;&#65362;&#65353;&#65360;&#65364;&#65310;&#65345;&#65356;&#65349;&#65362;&#65364;&#65288;&#65282;&#65349;&#65358;&#65347;&#65359;&#65348;&#65349;&#65348;&#65282;&#65289;&#65308;&#65295;&#65363;&#65347;&#65362;&#65353;&#65360;&#65364;&#65310;' -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>

airween commented 2 weeks ago

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.

xzhang-ipipeline commented 2 weeks ago

Thanks for looking into this @airween . I'll close the issue.