Hi Achim,
Good to hear from you. Unfortunately, nobody else responded. We'll
see how far we can get.
On Tue, Mar 03, 2015 at 09:00:35AM +0100, Achim wrote:
> this is a typical "header injection" attack. AFAIK CRS has no spezial
> rules for that. What best fits is the HTTP Response Splitting rule 950911,
> but it is far to specific to match in this case.
You hit the nail on the head. We first had a response splitting
vulnerability. Then we lowered the limit (which had been raised by
a sysadmin on his own), then the pen-tester worked around the lower
limit with this redirect vulnerability scoring 3 on the core ruleset.
> I'd suggest to craft a new set of rules for header injections.
I think that is due.
> Also a variant of your example would be the meta tag, if the aplication
> writes the paramter there.
Agreed.
> In OWASP Top 10 (2013) this is A1 and A10.
dito
So what can we do? I must say I am a bit at loss when thinking about a
good _generic_ approach.
(1) Disallow CR/LF in Query-Strings
This seems do-able, but it does not help us with request bodies
(2) Disallow CR/LF in Query-Strings and Request Bodies
This will raise a ton of false positives. But tuning them away
on certain input fields could do the job
(3) Disallow CR/LF in Query-Strings and Request Bodies in combination
with certain keywords
This might bring less false positives, but "Refresh" is a standard
word, so you can not rule them out.
What keywords would need to be covered to address the issue?
What transformation / escape variants?
(4) Disallow refresh header / meta tag in response phases
Will only work when ResponseBodyAccess is enabled.
And I think there are are still tons of applications around who
redirect applications in this way. -> False Positives
(5) Define a list of allowed redirects, then disallow refresh headers /
meta tags not pointing to these hosts/domains.
I am not sure if such a list / variable-to-take-this-list
exists in the core rules. It's definitely a pain in the A* to
maintain. And the restriction with ResponseBodyAccess
in (4) applies too.
I am not particularly fond of all these variants and I would appreciate
if somebody had a better idea.
Ahoj,
Christian
P.S. I will talk about practical CRS Tuning in Berne, Switzerland,
next Tuesday, 4pm. If anybody wants to join.
More infos here: http://www.sig-switzerland.ch/de/event_bern.php
--
Any technology that does not appear magical is insufficiently
advanced.
-- Gregory Benford
_______________________________________________
Owasp-modsecurity-core-rule-set mailing list
Owasp-modsecurity-core-rule-set@lists.owasp.org
https://lists.owasp.org/mailman/listinfo/owasp-modsecurity-core-rule-set
