- From: Eduardo' Vela\ <evn@google.com>
- Date: Tue, 13 May 2014 20:40:52 -0700
- 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