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. `._.-(,_..'--(,_..'`-.;.'