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:32:17 -0700
Message-ID: <CAFswPa_C6G=7v_diEL4mLji+WTLdyJqY+AHiciF6H=6aAxScYw@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>
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:33:00 UTC

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