False Positive REQUEST-941-APPLICATION-ATTACK-XSS / 941101 With Referer Headers With a Space and On

Description

This is not a new issue; it has been encountered several times before as described in these issues:

• https://github.com/coreruleset/coreruleset/issues/2219
• https://github.com/SpiderLabs/ModSecurity/issues/2426
• Probably several hundred more.

I wanted to add some additional analysis as well as a description for a small test case:

Assume you have a Referer header of: https://example.com/api?var=Press Onward&var=Son and the above rule enabled. This should trigger the rule.

The triggers appear to be:

1. A GET Variable value that has a space in it
2. The Space must be followed by two letters On and something else (Onward, One, Once, Ontological, etc)
3. The GET Variable must be followed by another get variable

The issue appears to be with the @detectXSS operator (https://github.com/SpiderLabs/ModSecurity/blob/c3b7a7f4f0cc5b14fd133cd27748121cbff0fe6a/src/operators/detect_xss.cc#L32) however if you look at the code it really is just calling down to libinjection_xss.

Looking at that code (assuming its this maintained fork: https://github.com/libinjection/libinjection/blob/main/src/libinjection_xss.c) the code gets a little hairy but if you use the following test program you can see where the error occurs:

int main()
{
    std::cout << "String contained XSS Injection";
    std::cout << libinjection_xss("https://example.com/api?var=Press Onward&var=Son", 48);
}

Triggers the detection of JavaScript On: https://github.com/libinjection/libinjection/blob/49904c42a6e68dc8f16c022c693e897e4010a06c/src/libinjection_xss.c#L343

The bug is a pretty bad combination of things: having spaces in GET variables, the length of the variable, an underlying third party library, and difficult to reproduce scenarios.

I am able to reproduce this on demand in an internal application with Azure’s WAF (albeit with a much more complicated request).

I wanted to at least point someone in the right direction (pinging @zimmerle) at minimum the library author is aware of at least one place that this manifests (See https://github.com/libinjection/libinjection/issues/9) but this can really trigger in a number of places.

Confirmation

[x] I have removed any personal data (email addresses, IP addresses, passwords, domain names) from any logs posted.

[dune73]

Yes.

Sorry @aolszowka.

[RedXanadu]

libinjection issue. Are we closing this?