Re: [whatwg] AppCache Content-Type Security Considerations

On Mon, May 12, 2014 at 4:17 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Mon, 12 May 2014, Eduardo' Vela\" <Nava> wrote:
> >
> > 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.
>
> 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.)
>

This seems to imply MIME types should always be ignored, is that actually
the case? I mean, it's clearly possible to have a file that is both, valid
CSS and valid JS.

I think what you actually mean is that the browser (with the context it
has, such as, being included in a <script or a @import) should be able to
make decisions re the way to parse the data it receives.

> 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.
>
> I don't really see a way to really fix this short of dropping FALLBACK
> support entirely.
>

I agree it's a tough problem, and I was hoping we could find another
solution :)

(The Content-Type is a bit of a red herring here. If you can prevent the
> attacker from overriding the Content-Type, you can prevent them from
> sending the appcache signature also.)
>

The author feedback that made the CT check to be dropped is that it was too
hard for authors to set CT, but it was easy to set the appcache signature.

The "attacker" will usually have the same (and more) constrains than what
the author has (although, attackers might be more tech savy than their
victim site owners in some cases).

In usual (and complex) web applications, it's not as common to be able to
set the Content Type as it is to be able to control the first few bytes
(think JSONP endpoints for example - but exporting data in text format is
another example).

> The way you make sure FALLBACK triggers every time (and not just when
> > the user is offline) is by means of Cookie Bombing. While similar
> > attacks were already possible before via other mechanisms such as
> > localStorage and the FileSystem API and such, they were always kept at
> > bay, and this makes things worse.
>
> "Cookie Bombing" (causing the user agent to send an HTTP request that's
> bigger than the server accepts) should IMHO be resolved by setting an
> upper limit on what clients can send in cookies, and having user agent
> enforce this limit. Server would then know that they need to support that
> much and no more for cookies.
>

Yes, I agree. This was an example of a simple client DoS attack.

 > 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.
>
> When you're online, only resources that actually specify the given
> manifest can be taken over.
>
> > One idea is with a special CSP policy that forbids manifest files from
> > working without the right CT
>
> I don't think limiting it to Content-Types is a real fix, but we could
> mark, with CSP, that the domain doesn't support appcache at all.

The problem I see with the CSP approach is that only pages that have CSP
will be protected.

 > or by means of per-page suborigins
>
> I don't know that we need to go to that length.
>
> We could, though, say that a manifest can only do fallbacks for URLs that
> are within the subpath that the manifest finds itself in. That would be an
> interesting way of scoping manifests on shared domains.
>

This is how crossdomain.xml works, so it might make sense. But I'm not sure
if that would be sufficient.

>  --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Monday, 12 May 2014 23:31:01 UTC