Rule 921160 matches with empty lines and looks for non-existing HTTP headers

_Issue originally created by user mentalstring on date 2017-11-13 22:36:02. Link to original issue: https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/955._

I’m new to mod_security so I hope I’m not missing something obvious… but I believe there’s a couple of issues with the regex of rule 921160 (HTTP Header Injection Attack via payload (CR/LF and header-name detected).

SecRule ARGS_NAMES|ARGS|XML:/* "(?:\n|\r)+(?:\s+|location|refresh|(?:set-)?cookie|(X-)?(?:forwarded-(?:for|host|server)|host|via|remote-ip|remote-addr|originating-IP))\s*:"

The first issue: empty lines followed by just : will cause a FP. For example, it will match with the body of a POST that just contains:

"

:-)"

or, in other words, it will match without an actual (injected) HTTP header being present.

The second issue is the placement of parenthesis on the (X-)? part of the regex: I’m not completely familiar with this type of attack, is it intended to look for headers such as X-remote-addr or X-via? And, shouldn’t that be a non-capturing?

This is on owasp-modsecurity-crs-3.0.2.

[CRS-migration-bot]

User lifeforms commented on date 2018-12-15 16:09:17:

Agreed franbuehler IIRC we removed the POST content exactly because of this problem - Thanks for the detailed review!

[CRS-migration-bot]

User franbuehler commented on date 2018-12-15 11:29:40:

In my opinion, this FP has been solved.

In Commit https://github.com/SpiderLabs/owasp-modsecurity-crs/commit/0d5110dcebefa1b845a06635d267b20b03d378c7, ARGS has been replaced with ARGS_GET. The post body is thus not checked anymore.

The problem was, that the minimum payload \n\s: triggered rule 921160:

 :

In the RFC 2616 (https://tools.ietf.org/html/rfc2616#page-31) I can not see if a headers name can consist of spaces:

message-header = field-name ":" [field-value]
       field-name = token
       field-value = * (field-content | LWS)
       field-content = <the OCTET's making up the field-value
                        and consisting of either * TEXT or combinations
                        of token, separators, and quoted-string>

But I think spaces are not forbidden and therefore (?:\n|\r)(?:\s*)?(?:location|refresh|(?:set-)?cookie|(?:x-)?(?:forwarded-(?:for|host|server))|host|via|remote-(?:ip|addr)|originating-ip)\s*: instead of (?:\n|\r)+(?:\s|location|refresh|(?:set-)?cookie|(?:x-)?(?:forwarded-(?:for|host|server)|host|via|remote-ip|remote-addr|originating-IP))\s*: is not an option. But I am not sure.

I would close this issue at the moment without further adjustment of the rule, because:

• this reported FP was eliminated
• since then no more FP were reported
• we potentially create a gap in the rule, when empty header names are not checked

Can I close the issue with this reason or are there counterarguments?