25699 2014-05-13 23:49:02 +0000 appcache: limit FALLBACK namespaces entries to subpaths of the manifest itself (not just same-origin) 2014-09-03 21:39:42 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED FIXED P3 critical Unsorted 1 ian ian aaj+w3c fbraun hbambas hober0 ian johnme jonas mike w3c zcorpan contributor oldest_to_newest 105932 0 ian 2014-05-13 23:49:02 +0000 Right now, if you XSS a site and inject a manifest into a page, that manifest can take over the entire origin. If we limit FALLBACK entries to only being subpaths of the manifest's URL, it would mitigate this to only being able to take over the section of the origin where the manifest is being hosted. Usually, you're not going to be able to upload a manifest into the root of the origin, one hopes. Question: is this sufficiently Web-compatible? 106159 1 zcorpan 2014-05-16 13:11:09 +0000 In webdevdata data set 2013-09-01 102,000 pages I see 4 sites having non-root manifests timer-tab.com manifest='sf/main.appcache' 20thingsilearned.com manifest="/en-US/cache.manifest?v=49" greynium.com manifest="http://www.greynium.com/wp-content/themes/greynium/cache.manifest" ptable.com manifest="Static/manifest.remove" Some of them have since changed, and none of them use FALLBACK today as far as I can tell. It's possible that manifests are more common in intranets though. A slightly more aggressive approach could be to disable FALLBACK if the manifest is not at the root. 106251 2 aaj+w3c 2014-05-17 23:04:03 +0000 So the goal here is only to prevent the manifest from hijacking unrelated legitimate resource loads from the manifest's origin, correct? IIUC this wouldn't prevent a potentially evil manifest entry from re-introducing an evil script to the XSS-ed origin. The attacker could just specify a FALLBACK entry for a subpath of the manifest's URL pointing to an evil resource, and have it execute in the context of the vulnerable domain at some point in the future. 106368 3 ian 2014-05-19 19:52:06 +0000 The problem isn't so much preventing XSS — to do anything here you have to have an XSS vector — the problem is more about preventing a reflecting XSS vector from being leveraged into a site-wide redirect for the targeted user, causing all content to redirect to a given page. Just being able to run _script_ doesn't let you escalate your manifest privileges, you need some way to get the site to serve a manifest as well. The idea of this mitigation is that the site's vulnerability with respect to where a file can be uploaded is likely to not always be on the root. 107009 4 hbambas 2014-05-29 22:47:25 +0000 To make it more clear: we want to limit the _namespace_ of a FALLBACK entry, not the target fallback resource we redirect to on an error. According our global telemetry top level pages loaded from appcache is around 0.01% of all cached page loads. In numbers, it's ~3.3M top level page loads from appcache per one of our release cycles (6 weeks) on the release channel. I personally have no more data to base the decision on, but appcache is a dead technology that should be altered with Service Workers - in progress. According a browser implementation I could imagine an error page (similar to SSL certificate error page) appearing when falling back to root/outside the manifest containing path. A warning message + suggestion to report the problem to owner of the site would appear. Potentially, user would be able to continue on its own risk. 110931 5 ian 2014-09-03 21:39:27 +0000 Ok, I've specced the mitigation described here. Let me know if browsers don't want to implement this. Not sure what else we can do, but we can at least mention in the spec that the mitigation, such as it is, hasn't been implemented. 110932 6 contributor 2014-09-03 21:39:42 +0000 Checked in as WHATWG revision r8739. Check-in comment: Attempt to mitigate the injection elevation attack on appcache, and describe the attack in detail http://html5.org/tools/web-apps-tracker?from=8738&to=8739