Is EnableHeaderChecking=true enough to prevent Http Header Injection attacks?
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..)
Answer
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:
- There is only one way to add custom HTTP headers to an HTTP response, namely using the HttpResponse.AppendHeader method
- HttpResponse.AppendHeader either
- creates instances of
HttpResponseHeader(internal) - or calls
HttpResponseHeader.MaybeEncodeHeader(forIIS7WorkerRequests) - or assigns its respective properties (for known headers like RedirectLocation or ContentType)
- creates instances of
HttpResponseHeaderinstances are created before known headers like RedirectLocation or ContentType are sent (HttpResponse.GenerateResponseHeaders)- The
HttpResponseHeaderconstructor checks the EnableheaderChecking setting and callsHttpResponseHeader.MaybeEncodeHeaderwhen set totrue HttpResponseHeader.MaybeEncodeHeadercorrectly encodes newline characters which makes HTTP header injection attacks impossible
Here 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.