- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Wed, 16 Dec 2009 12:55:27 -0800
- 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 UTC