Re: [whatwg] AppCache Content-Type Security Considerations

If CSS, JS and plugins had magic numbers at the beginning of the file, then
that would prevent the issues that you are discussing right?

I think that's Ian's point, that for those file types, we need CT, but for
others, like manifest files, and image and plugins we shouldn't need.

PDFs, and JARs are a special case here, since they scan the content (first
N bytes, or last N bytes) for the signature, but if the content match was
done for the exact first byte, then this would help prevent security issues
I think?




On Tue, May 13, 2014 at 8:00 PM, Michal Zalewski <lcamtuf@coredump.cx>wrote:

> > I disagree. Much of the Web actually relies on this today, and for the
> > most part it works. For example, when you do:
> >
> >    <img src="foo" ...>
> >
> > ...the Content-Type is ignored except for SVG.
>
> Well, <img> is actually a fairly special case of content that is
> difficult for attackers to spoof and that can't be easily read back
> across domains without additional CORS headers. But I believe that in
> Chrome and in Firefox, C-T checks or other mitigations have been
> recently added at least <script>, <link rel=stylesheet>, and <object>
> / <embed>, all of which lead to interesting security problems when
> they are used to load other types of documents across origins. Similar
> changes are being made also for a couple of other cases, such as <a
> download>.
>
> /mz
>

Received on Wednesday, 14 May 2014 03:04:28 UTC