Menu
Is it sufficient to have [System.Web.Configuration.HttpRuntimeSection.EnableHeaderChecking](http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx) set to true (default) to fully prevent Http Header Injection attacks like Response Splitting etc.?
I'm asking because a white box penetration testing tool (fortify) reports exploitable http header injection issues with HttpResponse.Redirect and cookies but I haven't found a way to successfully perform an attack. (edit:..and we have EnableHeaderChecking turned on..)
481
HTTP header injection is a technique that can be used to facilitate malicious attacks such as cross-site scripting, web cache poisoning, and more. These, in turn, may lead to information disclosure, use of your application in phishing attacks, and other severe consequences.
Description: HTTP response header injection HTTP response header injection vulnerabilities arise when user-supplied data is copied into a response header in an unsafe way.
HTTP Host header attacks exploit vulnerable websites that handle the value of the Host header in an unsafe way. If the server implicitly trusts the Host header, and fails to validate or escape it properly, an attacker may be able to use this input to inject harmful payloads that manipulate server-side behavior.
However, if a web-server relies on the supplied value of the Host header, a malicious user can provide a spoofed value to generate misleading links on your website and in transactional emails.
I've been looking at this for some time now and draw the conclusion that setting EnableHeaderChecking to true is in fact good enough to prevent http header injection attacks.
Looking at 'reflected' ASP.NET code, I found that:
HttpResponseHeader (internal)HttpResponseHeader.MaybeEncodeHeader (for IIS7WorkerRequests)HttpResponseHeader instances are created before known headers like RedirectLocation or ContentType are sent (HttpResponse.GenerateResponseHeaders)HttpResponseHeader constructor checks the EnableheaderChecking setting and calls HttpResponseHeader.MaybeEncodeHeader when set to true
HttpResponseHeader.MaybeEncodeHeader correctly encodes newline characters which makes HTTP header injection attacks impossibleHere is a snippet to roughly demonstrate how I tested:
// simple http response splitting attack
Response.AddHeader("foo", "bar\n" +
// injected http response, bad if user provided
"HTTP/1.1 200 OK\n" +
"Content-Length: 19\n" +
"Content-Type: text/html\n\n" +
"<html>danger</html>"
);
The above only works if you explicitly turn EnableHeaderChecking off:
<httpRuntime enableHeaderChecking="false"/>Fortify simply doesn't take configuration into account (setting EnableHeaderChecking explicitly had no effect) and thus always reports these type of issues.
111
AFAIK it's enough and it should be turned on by default.
I think Fortify is just thinking about defence in depth as if you change the configuration in the deployment etc.
I assume you did not strictly set it on in your configuration, if you have maybe Fortify is not that smart to figure that our.
Best way to confirm is exploiting it :)
26
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
