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

Re: [whatwg] AppCache Content-Type Security Considerations

From: Michal Zalewski <lcamtuf@coredump.cx>
Date: Tue, 13 May 2014 10:13:27 -0700
Message-ID: <CALx_OUD4Wf9jhPf1ro8g1eFTm9HWacJ98HspLQk6grzs9PfyUg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg <whatwg@lists.whatwg.org>, "Eduardo' Vela\\ <Nava>" <evn@google.com>, Adam Barth <w3c@adambarth.com>
> We probably can't support a well-defined algorithm for detecting
> documents that have distinctive signatures while safely supporting
> formats that don't have them (because there is always a possibility
> that the non-structured format with user-controlled data could be used
> to forge a signature).

It can be argued that the burden of detecting this should be placed on
the server before sending out the response, but this would be a fairly
major shift in what is currently assumed to be the web security model
(with detrimental effect on tens of thousands of existing web apps);
on top of that, it would cripple some legitimate uses of the
non-structured formats: for example, there may be perfectly legitimate
reasons why a text/plain or text/csv document also matches a signature
for HTML.

In general, in the past, in pretty much every single instance where
browsers tried to second-guess Content-Type or Content-Disposition
headers - be it through sketchy proprietary content-sniffing
heuristics or through well-defined algorithms - this ended up creating
tons of hard-to-fix security problems and introduced new burdens for
web developers. It looks elegant, but it's almost always a huge
liability.

I think that most or all browsers are moving pretty firmly in the
other direction, enforcing C-T checking even in situations that
historically were off-limits (<script>, <style>, <object>, etc), based
on strong evidence of previous mishaps; to the extent that the spec
diverges from this, I suspect that it will be only a source of
confusion and incompatibility.

/mz
Received on Tuesday, 13 May 2014 17:14:11 UTC

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