Re: [whatwg] AppCache Content-Type Security Considerations

>> Note that there _is_ still a content type check with appcache, it's just
>> done on the first few bytes of the file instead of on the metadata. (This
>> is IMHO how all file typing should work.)
>
> There's a big difference between the first few bytes of a file and the
> Content-Type HTTP header.  In many scenarios, the former is under the
> control of an attacker when the latter is not.

Yup, from the perspective of a significant proportion of modern
websites, MIME sniffing would be almost certainly a disaster. For
example, many websites rely on the ability to tell the browser that a
particular file should be interpreted as a profile image supplied by
the user, and not any form of "active" content.

Server-side validation does not help, because some formats do not have
unique signatures (e.g., CSV, plain text), while others can be
structured so that they are valid to more than one parser - say,
http://lcamtuf.coredump.cx/squirrel/.

While content sniffing might be a more fault-tolerant solution, I'm
pretty sure we can't go there without major casualties. In fact,
Microsoft spent several years to waltz out of content sniffing in
their browser, and C-T matching has been tightened up in most browsers
even on subsresources such as <script> or <style> to close a number of
significant security attacks (for example, it turns out that many
cross-origin HTML documents can be also parsed as CSS, with observable
side effects [1]).

/mz

[1] http://scarybeastsecurity.blogspot.com/2009/12/generic-cross-browser-cross-domain.html

Received on Tuesday, 13 May 2014 00:36:58 UTC