W3C home > Mailing lists > Public > whatwg@whatwg.org > May 2014

Re: [whatwg] AppCache Content-Type Security Considerations

From: Eduardo' Vela\ <evn@google.com>
Date: Tue, 13 May 2014 20:03:44 -0700
Message-ID: <CAFswPa-LfJyby2W-aF_2pZC9GdUabpUrxx=3zAKp7np-aLcmQQ@mail.gmail.com>
To: Michal Zalewski <lcamtuf@coredump.cx>
Cc: whatwg <whatwg@lists.whatwg.org>, Ian Hickson <ian@hixie.ch>, Adam Barth <w3c@adambarth.com>
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

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:20 UTC