Description
Issue originally created by user lifeforms on date 2016-10-21 16:17:42.
Link to original issue: SpiderLabs/owasp-modsecurity-crs#623.
Rule 921150 (PL1; HTTP Header Injection Attack via payload (CR/LF deteced)) disallows \r and \n in ARGS_GET. This seems too overbroad since it will block any GET form with a newline.
Test: curl 'http://localhost/?text=its%0D%0Ame'
I think this rule is not very productive. It just matches on (\n|\r) in ARGS_NAMES (fair enough) and ARGS_GET (that seems WAY too strict, especially for PL1).
If we want to check for header injection, it seems much better to match on something that looks like an actual HTTP header name: (\n|\r)\s*[\w\d\s_-]*: There is some precedent for that, there are already similar rules listing some blacklisted HTTP headers specifically (921120 and 921160).
Even if we make rule 921150 more specific to look for a full header name, I still think it will hit some false positives though. But maybe not at the current unsustainable level.
So I think we should either:
- extract ARGS_GET checking of
(\n|\r)to a separate rule at higher level, e.g. PL3-PL4, and see how the rest of the rule fares (quick win) - match on anything that looks like a real header, however, since we already have a blacklist in PL1, we might do this in PL2 (this option would involve some work)