W3C home > Mailing lists > Public > public-web-security@w3.org > December 2009

Re: Handling multiple headers when only one is allowed

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Wed, 16 Dec 2009 12:55:27 -0800
Message-ID: <448e9a320912161255v4d34a6a3h2b3a2f6de9a475c7@mail.gmail.com>
To: Bil Corry <bil@corry.biz>
Cc: public-web-security@w3.org
> 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
"Content-Disposition".

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?

/mz
Received on Wednesday, 16 December 2009 22:34:20 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 19 December 2010 00:16:01 GMT