[whatwg] First or last Content-Type header?

On Mon, Jun 1, 2009 at 2:55 PM, Den.Molib <den.molib at gmail.com> wrote:
> The only case of double headers I can think of is when using scripts
> that set a content-type, then try to set it again and the language
> itself don't prevent it.
> I think the "right" option in such case would be to follow the last one,
> as it's the one provided nearer the content.

On Mon, Jun 1, 2009 at 4:25 PM, Bil Corry <bil at corry.biz> wrote:
> And by the same logic, the header closest to the content could be the one that was injected by an attacker (via application hole) -- so might choosing the first header be more prudent?

On Tue, Jun 2, 2009 at 11:53 AM, Bil Corry <bil at corry.biz> wrote:
> Perhaps the better choice would be to toss out the multiple content-headers entirely and rely exclusively on content-sniffing.  Without the content-header, Firefox 3 correctly shows the image, and Internet Explorer incorrectly delivers the payload -- but your draft, if adopted, should fix that problem, correct?

"Den.Molib" <den.molib at gmail.com>
> 1. The server or the script language you used to inject the payload may
> be replacing the header when you add the second header.
> 2. Browsers in widespread use take into account the last header.
>
> Thus, presending a header is not a method to protect the app.

On Tue, Jun 2, 2009 at 4:24 PM, Bil Corry <bil at corry.biz> wrote:
> Are you referring to current browser behavior?  Or the proposed content-sniffing algorithm?  If you're talking about current browser behavior, then it does work for IE.
[...]
> The server should provide a single content-type header that specifies text/plain.  In the context that there are two content-type headers, then the answer will depend on which browser you want to protect; IE, set the first header to text/plain; all the others, set the last header to text/plain.
>
> And to be clear, if the content-sniffing draft decides to use the last header because it interoperates with the most sites, then I get that.  I just don't want to see it using a less secure method just because that's what 4 out 5 browsers currently do.

On Tue, Jun 2, 2009 at 4:51 PM, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> Sending a text/plain Content-Type will not prevent any
> (default-configured) version of IE from interpreting the file as HTML,
> even if it's the *only* Content-Type header sent.  This is why Adam
> Barth said "The only browser that uses the first header more or less
> ignores it anyway."  This apparently isn't fixed even in IE8: it
> insists on still upsniffing text/plain to text/html unless you use the
> nonstandard header "Content-Type: text/plain; authoritative=true;".
>
> (The reason given is compatibility.  As usual, Microsoft seems to have
> compatibility problems where all other browsers have been doing the
> right thing for years -- maybe because of their intranet usage share.
> IE8 at least won't treat image/* as HTML anymore.)
>
> So anyway, IE is irrelevant to this discussion.
>
> Reference: http://blogs.msdn.com/ie/archive/2008/07/02/ie8-security-part-v-comprehensive-protection.aspx

Based on this discussion, I'm not convinced there is a sufficiently
compelling security rationale for convincing 4 out of 5 browsers to
change their implementations.  The only attack presented is a header
injection attack.  If I can inject headers into your HTTP responses, I
can almost always perform a response splitting attack and obviate any
protections we might hope to gain by using the first Content-Type
header.

Adam

Received on Friday, 5 June 2009 01:44:25 UTC