[whatwg] AppCache Content-Type Security Considerations

Hi!

In the following bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=14701the Content-Type
requirement for AppCache manifest files was dropped, and
the security implications of such change probably weren't fully understood
at that time, and we want to start a discussion on this topic to ensure we
aren't doing something that might put some websites in danger.

First of all, to provide some background and establish a common ground. The
only security mechanism effectively provided by the browser is the web
origin[1], and those protections are commonly used across the industry to
isolate and protect user-provided content[2]. This allows, for example,
users to have blogs and websites well isolated from each other.  We can
easily justify creating an isolated origin for active content like HTML
files and so on, and every web author should do just that.

However, some files can be created in a safe format (such as a CSV file, or
a JSON response, or even an HTML file), and the Content-Type can be set
correctly (instructing the browser how it intends the data to be rendered)
and give the impression the file hosting is safe, when it actually isn't.
We used to see this problem before for Content-Type sniffing[3], in which
the browser would disregard the Content-Type of an HTTP request, but new
mechanisms such as X-Content-Type-Options: nosniff would come and save the
day. Today, for instance, TDC files[4], or PDF files[5], and before we had
JAR files[6], and we've seen similar problems arise from SWF files[7] and
crossdomain.xml files[8] resulting in a similar consequence. Historically
these are all have been browser plugins and extensions that create these
problems. We worked with the plugin maintainers to respect Content-Type, or
provide mechanisms to allow web authors to opt-out of the default insecure
behavior[9] (which is arguably very bad and wrong, as anyone that doesn't
know about this will be easily vulnerable =/, but I digress). There are
also "arbitrary" rules that make development somewhat safer against future
problems (thou shall not let the user control the first byte of an HTTP
response, thou shall not let the user inject NULL bytes or malformed UTF-8
sequences, thou shall not let the user control the content-type of an HTTP
response).

Now, with appcache manifest files, we are introducing a security-sensitive
change based on a file with special powers (more on this later), and while
before they were guarded by a Content-Type check, this isn't the case
anymore. We understand a lot of author feedback came into play when making
this decision of ignoring Content-Type, and we are not asking to revert it.
But rather, we want to ensure the risk is clearly understood, and the
solution codified in the standard balances the security risk with the
usability of the feature by web authors.

To clearly explain the risk, I'll lay down two use cases where this is
going to worsen things somewhat:

 1. When there is an XSS in your favorite website, and you are infected
with it. Thanks to FALLBACK the attacker can make it so that you can never
recover from the XSS (and be "infected" for ever). The way to do this is by
finding an endpoint in the vulnerable web application that lets you
generate a file that looks like a manifest file (this isn't hard - really),
and then force the browser to use it via your XSS. The way you make sure
FALLBACK triggers every time (and not just when the user is offline) is by
means of Cookie Bombing [10]. While similar attacks were already possible
before via other mechanisms [11] such as localStorage and the FileSystem
API and such, they were always kept at bay, and this makes things worse.
 2. CDNs and similar sites can be completely taken over for all the HTML
hosted in them. They will effectively break and reach an irrecoverable
state. While this isn't the case for resources like JS files, HTML files
enough are already a concern.

This attacks are particularly scary because they allow attackers to do
things that before wasn't possible. In specific persist access to their
victim's web application. We can clearly mitigate the risk in many ways.
One idea is with a special CSP policy that forbids manifest files from
working without the right CT, or by means of per-page suborigins[12] (which
reaches a similar deal-with-the-devil as crossdomain.xml files and Adobe),
but in an ideal world, we wouldn't have this problem in the first place.
Another alternative is to enforce and codify the semantics of
X-Content-Type-Options: nosniff for AppCache manifest files.

If we do nothing, it will significantly change the way we all have been
treating secure web content hosting, so let's to make sure all the security
implications are understood now, rather than later.

Thanks!!

[1] http://tools.ietf.org/html/rfc6454
[2] https://plus.sandbox.google.com/+EduardoVelaNava/posts/4riSfqjx2bj
[3] http://msdn.microsoft.com/en-us/library/ms775147.aspx
[4]
http://msdn.microsoft.com/en-us/library/ms531356%28v=VS.85%29.aspx#Understanding_the_TDC_Object_Model
[5] http://www.cse.chalmers.se/~andrei/ccs13.pdf
[6] http://xs-sniper.com/blog/2008/12/17/sun-fixes-gifars/
[7]
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/devnet/swf/pdf/swf-file-format-spec.pdf
[8] http://www.adobe.com/devnet/articles/crossdomain_policy_file_spec.html
[9]
http://www.adobe.com/devnet-docs/acrobatetk/tools/AppSec/xdomain.html#meta-vs-master-policies
[10]
http://sirdarckcat.blogspot.com/2009/04/how-to-use-google-analytics-to-dos.html
[11] http://research.google.com/pubs/pub37661.html
[12] http://www.chromium.org/developers/design-documents/per-page-suborigins

Received on Monday, 12 May 2014 20:54:08 UTC