Re: Handling multiple headers when only one is allowed

On Wed, 09 Jun 2010 02:18:00 +0200, Bil Corry <bil@corry.biz> wrote:

> 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?

I'd say it would be difficult, because whatever is decided it will be the  
wrong choice in many cases (when the server sends bad headers). I suspect  
that most clients picked their current method because some important site  
(e.g. a bank) broke because of the old way of doing things, which was  
opposite of what the (at the time) major competing client did at the time.

As far as I can see there are three choices for changing the current  
status:

   - Always pick the first
   - Always pick the last
   - Ignore all such double headers, and in the case of Content-Type,  
handle the document as an application/octet-stream and offer to save it to  
disk (no guessing allowed), or just discard the body (which might be the  
safest option) and tell the user "Could not display content due to  
conflicting instructions from the site".

In all three cases a site will break if it sends duplicate headers and  
rely on some specific manner (opposite of what is selected) for the  
content to be handled, but in the last case the result will be predictable.

Well, there is actually a fourth choice: Ask the user (Yes, I know, the  
user will most likely know just as little as the client about what those  
header were intended to mean, and the opportunities for social engineering  
attacks will be legion).

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Received on Wednesday, 9 June 2010 00:49:10 UTC