Re: Handling multiple headers when only one is allowed

> It would seem to me that using the first header would be slightly safer

To provide some context based on off-list discussions - probably the
most common example of a HTTP header splitting vulnerability is
newline injection through user-controlled "Location" header; a close
second would be newlines in user-specified file names in

In browsers where the last header takes precedence, these are
trivially exploitable; for example, in the "Location" case, the
attacker may inject a second, invalid "Location" header to prevent
page transition; and then follow with "Content-Type:
text/html\r\n\r\n<script>alert(1)</script>" to have this text
displayed as an error message instead. Or, in the C-D case, the
attacker could inject a second "Content-Disposition" that says
"inline", then do the same.

First header precedence, in contrast, usually makes these two cases
not exploitable, or exploitable with greater difficulty.

I strongly suspect there is no particular reason for the differences;
we also noticed that some new specs (such as the content sniffing spec
that Adam Barth worked on) try to sanction precedence for individual
headers such as C-T - but doing so for a single header is probably
harmful in the sense that it creates even more discrepancies (C-D,
Location, Refresh, Cache-Control, etc, all have security consequences
too, and should behave consistently).

I also suspect it may be difficult to get HTTP specs to specify
precedence at any point in the future, as they tend not to focus on
such earthly things; but perhaps HTML5 could specify a top-level rule
for all rendering-related headers within its scope?


Received on Wednesday, 16 December 2009 22:34:20 UTC