On Jul 9, 2012, at 7:24 PM, Adam Barth wrote:

> On Mon, Jul 9, 2012 at 4:19 PM, Richard L. Barnes <[email protected]> wrote:
>> I haven't thought much about this, but a couple of thoughts:
>> 
>> The binary prologue means that the document is not valid HTML, so in 
>> principle, it shouldn't be accepted as HTML.  It makes you wonder what other 
>> stuff you could put in there that the browser would stuff into the DOM 
>> without it being obvious on the wire, say, to a proxy.  I'm imagining things 
>> like encrypted / compressed Javascript code that could be unpacked by the 
>> more obviously HTML part of the page.
> 
> You don't have to imagine.  It's specified in HTML5.

Could you clarify?  What is "it"?  Reference would be helpful.

Is there really a use case for inserting into the DOM arbitrary octets that are 
not syntactically part of the HTML page?

--Richard



>> In a related vein, the "Text or Binary" section of 
>> draft-ietf-websec-mime-sniff says that nothing scriptable must come out of 
>> sniffing a binary blob.  Yet in this case, it produced "text/html", which is 
>> obviously scriptable.
> 
> The browser isn't sniffing HTML in this case.  The server sent a
> Content-Type header with text/html.
> 
> Adam
> 
> 
>> On Jul 9, 2012, at 5:05 PM, Adam Barth wrote:
>> 
>>> Why is this sniffing gone awry?  Nothing bad seems to have happened in
>>> this example.
>>> 
>>> Adam
>>> 
>>> 
>>> On Mon, Jul 9, 2012 at 1:55 PM, Richard L. Barnes <[email protected]> wrote:
>>>> Related to draft-ietf-websec-mime-sniff, an example of sniffing gone awry:
>>>> <http://lcamtuf.coredump.cx/squirrel/>
>>>> 
>>>> It's a valid JPEG image that contains and HTML snippet in a comment 
>>>> segment.  As a result, when a browser loads the URL expecting an image, it 
>>>> renders the image content, and when it expects HTML, it skips the binary 
>>>> junk at the top and renders the HTML [*]. (In both cases, the server 
>>>> reports Content-Type text/html.)   What's even more startling is that 
>>>> Chrome helpfully adds the binary junk at the top as the first child of the 
>>>> <body> element in the parsed DOM!
>>>> 
>>>> --Richard
>>>> 
>>>> 
>>>> [*] At least in Chrome 20.0.1132.47
>>>> _______________________________________________
>>>> websec mailing list
>>>> [email protected]
>>>> https://www.ietf.org/mailman/listinfo/websec
>> 

_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec

Reply via email to