Re: Handling multiple headers when only one is allowed

I don't think you can set a blanket rule for this, since it will depend 
on the header what the appropriate action is.

For instance if you receive 2 content-length headers with different 
lengths, it's probably unsafe to do anything other than reject the message.

Or if you get a Transfer-Encoding: chunked and a Transfer-Encoding: 
identity.

Or 2 or more different Content-Type headers, or even conflicting 
charsets.  Or multiple Content-Encoding headers.

Personally I don't think it's wise to "rely" on any particular 
hypothetical benefit (from a security standpoint) of order.  Any 
malicious inserter of headers should be considered to be able to 
potentially add headers anywhere in the header block.  So intrinsically 
I don't believe it's any safer to choose any particular one (first or 
last), and in fact it could be argued that picking a random one (if any) 
is more secure since it is harder for a malicious inserter of headers to 
predict where it must insert.

Are there any particular cases you have in mind of headers?  It might be 
safest to have a rule more like:

a) if the headers is optional, but can only exist once, then presence of 
more than one instance of the header should be treated as if the header 
were not present at all
b) if the header is required, reject the message.

In fact there are many ways to have conflicting headers, not just 
multiple instances of an unrepeatable header.

The spec for obvious reasons doesn't cover many of these (the number of 
combinations are very large).  It covers things like a message 
containing Content-Length and Transfer-encoding.

Cases which affect message delimiting are particularly problematic.  E.g 
a response which contains Connection: Keep-alive without a 
Content-Length nor Transfer-Encoding header, it's hard to tell what to 
do when you receive this, since the only way you can delimit the message 
boundary is if the server closes, which it indicated it wouldn't do.

Cheers

Adrien


On 9/06/2010 12:18 p.m., Bil Corry wrote:
> Michal Zalewski's excellent "Browser Security Handbook" points out that different browsers handle multiple headers differently when only one header is suppose to be present (scroll down to "First HTTP header of the same name takes precedence?"):
>
>  http://code.google.com/p/browsersec/wiki/Part1#Hypertext_Transfer_Protocol
>
> Essentially, the first header takes precedence for Internet Explorer and Safari while Firefox, Opera and Chrome use the last header.
>
> In a similar thread I brought up on another list[1], Michal Zalewski explained the security implications of this issue[2], Julian Reschke pointed out that there's already a similar issue open[3] and Mark Nottingham suggested I bring it up here[4].
>
> To summarize the issue, when a user-agent encounters multiple headers of the same name when only one is allowed, it must decide which header, if any, will be used.  The argument for using the first header centers on the premise that an attacker most likely will be injecting headers below the real header.  The argument for using the last header centers on the premise that sometimes web developers do not control the entire server, and thus can not control headers added by the server, but are able to add additional headers.
>
> Given the mixed implementations among user-agents and the security implications therein, is it possible for this to be defined?
>
>
> - Bil
>
>
> [1] http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0221.html
> [2] http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0223.html
> [3] http://trac.tools.ietf.org/wg/httpbis/trac/ticket/95
> [4] http://lists.w3.org/Archives/Public/public-web-security/2009Dec/0226.html
>
>

Received on Wednesday, 9 June 2010 00:37:36 UTC