XSS Bypass #2170
Comments
|
Hmm. It's definitely a false negative, but I wonder if adding REQUEST_FILENAME at PL1 won't lead to a lot of false negatives. We could add it o 941101 at PL2 where we currently scan the referer. Not sure if we have discussed this before. @lifeforms: What is your stance on this? |
|
There was already a similar discussion in #1022 and REQUEST_FILENAME is already included in Rule-ID 941110. Unfortunately, I am not that familiar with the rules, so I am not sure in which rule(s) the REQUEST_FILENAME should be included. (in view of false positives) |
|
Thank you for the pointer, I had this at the back of my head ... 941110 is nice, but it's a completely different rule. 941100 at PL1 and 941101 at PL2 use the same mechanics (the detectXSS operator provided by libinjection). We call this construct strict siblings. 941101 is a strict sibling to 941100. It's the same rule, but a bit tougher. Here we use the 941101 rule to include items where we expect more false positives. REQUEST_FILENAME can fall into that category and be added at PL2 in 941101, or we come to the conclusion PL1 is fine so we add it to PL1. It's a pity we did not finish the discussion in #1022 years ago or you would not be facing this now. |
|
I have another report with the following payload that goes undetected in default install: Adding REQUEST_FILENAME to 941100 or 941101 (PL2) does the trick. |
|
@dune73 What path should we follow then? @lifeforms? |
|
We have not heard from @lifeforms, but I am strongly in favor of 941101 at PL2. If we do not hear other opinions, somebody could provide a PR, or you add it to the agenda for Monday or the issue chat in two weeks. |
|
I have a vague recollection that years back I tried to add REQUEST_FILENAME to some XSS rules, and ultimately had to revert those changes because of many false positives, but I am not completely sure anymore. I am may be confusing it with a different scenario (we also had lots of trouble with XSS rules on the Referrer header which caused some reverts). I am trying desperately to find my old notes, but no luck. Ideally we would enable XSS checks on filenames as much as we can. It would be a workable compromise to add REQUEST_FILENAME in a stricter sibling at PL2 and see how it behaves in practice - with the option of reverting it before release if the false positive rate is unacceptable. |
|
Note to self: re-read full issue, create PR, maybe also test case. |
|
Issue covered in the September issue chat. @RedXanadu volunteered to do a PR. @lifeforms would like to get a ping then so he can test the PR in production and it's also a candidate for our incubator plugin where we want to test rules before we adopt them into the mainline. |
|
This has now been resolved since PR #2208 was merged a few days ago. @lifeforms: It was mentioned the other month that you may want to test this in production. (Summary: |
|
Closing issue as resolved, unless there are any objections. |
Motivation
We run some sites having mod_security with the OWASP-Core Ruleset 3.3.0 enabled. (thanks for your work ;))
After doing some security analysis, we found out, that some requests bypassed modsecurity and led to successful XSS attacks.
Such an example request would be:
GET https://mysite.com/en/search/%3Cimg+src%3Dx+onerror%3Dalert%281%29%3B%3EIn my opinion, the XSS-Attacks are not checked against the Request-Path. (only COOKIES, ARGS, ARG_NAMES, XML, HEADERS, ...)
Proposed solution
Include REQUEST_FILENAME in the XSS-Detection rules. (in REQUEST-941-APPLICATION-ATTACK-XSS.conf)
e.g.
After applying these changes, the XSS attacks were correctly blocked.
Alternatives
Additional context
The text was updated successfully, but these errors were encountered: