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:40:52 -0700
Message-ID: <CAFswPa8ytDFn5C6Ri6+kKc-OtjKBYT4oTgTa=ckju96LT2_LuA@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>
@Ian, is there a way to find out what was the Content-Type that the authors
that complained were getting?

Hopefully we can figure out a list of Content-Types that are unlikely to
cause security problems?

On Tue, May 13, 2014 at 8:32 PM, Eduardo' Vela" <Nava> <evn@google.com>wrote:

> So today, we need CT for JSONP and CSV. Those are the ones we *need* CT.
> The idea is to train the browser to recognize the CTs of formats that are
> ambiguous.
> On Tue, May 13, 2014 at 8:26 PM, Michal Zalewski <lcamtuf@coredump.cx>wrote:
>> > 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.
>> If we take this route, I think we'd be essentially making sure that
>> many web applications that are safe today will gradually acquire new
>> security bugs out of the blue as the UA "magic signature" detection
>> logic is extended in the future (as it inevitably will - to account
>> for new plugins, new formats with scripting capabilities or other
>> interesting side effects, etc).
>> An out-of-band signalling mechanism has far superior security
>> properties compares to an in-band one, given how many if not most web
>> apps are designed today. It may be that they are designed the "wrong"
>> way, but the security rules were never particularly clear, and serving
>> content off-domain added a lot of complexity around topics such as
>> auth, so I think it's best to be forgiving and accommodate that. The
>> examples of CSV exports, text documents, and several more exotic
>> things aside, most JSONP APIs give the attacker broad control over the
>> first few bytes of the response.
>> /mz
Received on Wednesday, 14 May 2014 03:41:35 UTC

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