CODEWITHSUNDEEP
asp.netiissecurityfortify
Josef Pfleger
Josef Pfleger

Reputation: 74517

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..)

Upvotes: 11

Views: 26344

Answers (4)

Douglas Held
Douglas Held

Reputation: 1461

Josef, HttpResponse.AppendHeader() is not the only place where untrusted data can enter the HTTP Response Headers.

Any data from the attacker that ends up in Cookies or HTTP redirects can write new headers if the data contains a carriage return (or anything that is interpreted as a carriage return).

In general, it's a much better use of your time to validate your data than to sit around and try to work out exploits. Chances are, the hackers are going to be better at this than you or I are.

Upvotes: 0

Josef Pfleger
Josef Pfleger

Reputation: 74517

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:

  1. There is only one way to add custom HTTP headers to an HTTP response, namely using the HttpResponse.AppendHeader method
  2. HttpResponse.AppendHeader either
    • creates instances of HttpResponseHeader (internal)
    • or calls HttpResponseHeader.MaybeEncodeHeader (for IIS7WorkerRequests)
    • or assigns its respective properties (for known headers like RedirectLocation or ContentType)
  3. HttpResponseHeader instances are created before known headers like RedirectLocation or ContentType are sent (HttpResponse.GenerateResponseHeaders)
  4. The HttpResponseHeader constructor checks the EnableheaderChecking setting and calls HttpResponseHeader.MaybeEncodeHeader when set to true
  5. 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.

Upvotes: 8

dr. evil
dr. evil

Reputation: 27265

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.

Upvotes: 1

nessence
nessence

Reputation: 579

EnableHeaderChecking is only for untrusted data. If you're passing data directly from a cookie into a Redirect, maybe the resulting headers are considered trusted and \r\n values aren't escaped.

Upvotes: 0

Related Questions