Is EnableHeaderChecking=true enough to prevent Http Header Injection attacks?
Solution 1
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
-
HttpResponseHeader
instances are created before known headers like RedirectLocation or ContentType are sent (HttpResponse.GenerateResponseHeaders
) - The
HttpResponseHeader
constructor checks the EnableheaderChecking setting and callsHttpResponseHeader.MaybeEncodeHeader
when set totrue
-
HttpResponseHeader.MaybeEncodeHeader
correctly 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.
Solution 2
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 :)
- Just get a copy of fiddler
- Intercept the request
- Try to inject new line
- See if the new line you've just injected is in the HTTP response or not.
Josef Pfleger
Interested in computers, especially software and its creation. And airplanes.
Updated on July 20, 2022Comments
-
Josef Pfleger almost 2 years
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 totrue
(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..) -
Josef Pfleger almost 15 years(: trust me, I've tried to exploit this. And there are better tools than fiddler, I personally like Charles and the Tamper Data Firefox add-on.
-
alice7 almost 15 yearsHi Josef the code for testing the injection that you wrote above. I need to where we can paste this code to test my application. I need to test my application as well. thnx
-
Josef Pfleger almost 14 yearsFor well known Headers like Cookies or Redirects, ASP.NET already has checks in place (e.g. have a look at the reflected
HttpResponse.Redirect
), but custom headers all go throughAppendHeader
. Of course we do our best to validate data but since Fortify showed Response Splitting Attacks and others we looked atEnableHeaderChecking
.