Re: [whatwg] AppCache Content-Type Security Considerations

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.)


> 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.

(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 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.


> 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.


> 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.

-- 
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:18:01 UTC