- From: Michal Zalewski <lcamtuf@coredump.cx>
- Date: Tue, 13 May 2014 10:13:27 -0700
- 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