StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>I've been looking at this for some time now and draw the conclusion that setting <a href="http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx" rel="noreferrer">EnableHeaderChecking</a> to <code>true</code> is in fact good enough to prevent http header injection attacks.</p> <p>Looking at 'reflected' ASP.NET code, I found that:</p> <ol> <li>There is only one way to add custom HTTP headers to an HTTP response, namely using the <a href="http://msdn.microsoft.com/en-us/library/system.web.httpresponse.appendheader.aspx" rel="noreferrer">HttpResponse.AppendHeader</a> method</li> <li><a href="http://msdn.microsoft.com/en-us/library/system.web.httpresponse.appendheader.aspx" rel="noreferrer">HttpResponse.AppendHeader</a> either <ul> <li>creates instances of <code>HttpResponseHeader</code> (internal)</li> <li>or calls <code>HttpResponseHeader.MaybeEncodeHeader</code> (for <code>IIS7WorkerRequests</code>)</li> <li>or assigns its respective properties (for known headers like <a href="http://msdn.microsoft.com/en-us/library/system.web.httpresponse.redirectlocation.aspx" rel="noreferrer">RedirectLocation</a> or <a href="http://msdn.microsoft.com/en-us/library/system.web.httpresponse.contenttype.aspx" rel="noreferrer">ContentType</a>)</li> </ul></li> <li><code>HttpResponseHeader</code> instances are created before known headers like <a href="http://msdn.microsoft.com/en-us/library/system.web.httpresponse.redirectlocation.aspx" rel="noreferrer">RedirectLocation</a> or <a href="http://msdn.microsoft.com/en-us/library/system.web.httpresponse.contenttype.aspx" rel="noreferrer">ContentType</a> are sent (<code>HttpResponse.GenerateResponseHeaders</code>)</li> <li>The <code>HttpResponseHeader</code> constructor checks the <a href="http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx" rel="noreferrer">EnableheaderChecking</a> setting and calls <code>HttpResponseHeader.MaybeEncodeHeader</code> when set to <code>true</code></li> <li><code>HttpResponseHeader.MaybeEncodeHeader</code> correctly encodes newline characters which makes HTTP header injection attacks impossible</li> </ol> <p>Here is a snippet to roughly demonstrate how I tested:</p> <pre><code>// 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>" ); </code></pre> <p>The above only works if you explicitly turn <a href="http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx" rel="noreferrer">EnableHeaderChecking</a> off:</p> <pre><code><httpRuntime enableHeaderChecking="false"/></code></pre> <p>Fortify simply doesn't take configuration into account (setting <a href="http://msdn.microsoft.com/en-us/library/system.web.configuration.httpruntimesection.enableheaderchecking(VS.85).aspx" rel="noreferrer">EnableHeaderChecking</a> explicitly had no effect) and thus <em>always</em> reports these type of issues.</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload