Rule 921120: False positive #1615
Comments
|
User franbuehler commented on date 2020-03-02 14:53:53: Yes, I think this issue could be solved by adding a But, as far as I know empty headers are valid too, but they are ignored by the browser. So we potentially add an evasion here. That's why I would only add my suggested regex to the location header and not all of the headers in this rule. Other opinions? |
|
User dune73 commented on date 2020-03-02 14:58:34: No, I can not see where an empty contnt-type, content-length, set-cookie or location header can be considered standard behaviour. Sure, the protocol does allow it, but that does not mean that it happens in real life. |
|
User franbuehler commented on date 2020-03-02 15:02:23: So I add my suggested regex to all headers? |
|
User dune73 commented on date 2020-03-02 15:03:07: I think that should work, yes. |
|
User franbuehler commented on date 2020-03-02 15:08:02: Ok, I'll do that. Thanks for your fast feedback! |
|
User dune73 commented on date 2020-03-04 08:04:25: Decision during the CRS project chat on March 2, 2020: franbuehler will solve this. |
Issue originally created by user Taiki-San on date 2019-10-29 15:44:54.
Link to original issue: SpiderLabs/owasp-modsecurity-crs#1615.
Type of Issue
False positive.
Description
The regex doesn't check if there is a payload after fairly common keywords.
We had a false positive on the pattern
...\r\n\r\nlocation:\r\n....This specific case could have avoided if the regex was followed by something like
\s+\w+.What do you think?
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: