[giow] (3) Attempt to mitigate the injection elevation attack on appc…

…ache, and describe the attack in detail Fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=25699 Affected topics: Offline Web Applications, Security git-svn-id: http://svn.whatwg.org/webapps@8739 340c8d12-0b0e-0410-8428-c7bf67bfef74
whatwg · Sep 3, 2014 · 64f8389 · 64f8389
1 parent d27e0f4
commit 64f8389
Show file tree

Hide file tree

Showing 3 changed files with 151 additions and 17 deletions.
diff --git a/complete.html b/complete.html
diff --git a/index b/index
diff --git a/source b/source
@@ -81958,6 +81958,7 @@ NETWORK:
   </div>
 
 
+
   <h5>Writing cache manifests</h5>
 
   <p>Manifests must be served using the <code>text/cache-manifest</code> <span>MIME type</span>. All
@@ -82093,7 +82094,8 @@ NETWORK:
 
   <p><span data-x="concept-appcache-fallback-ns">Fallback namespaces</span> and <span
   data-x="concept-appcache-fallback">fallback entries</span> must have the <span>same origin</span>
-  as the manifest itself.</p>
+  as the manifest itself. <span data-x="concept-appcache-fallback-ns">Fallback namespaces</span>
+  must also be <span>in the same path</span> as the manifest's URL.</p>
 
   <p>A <span data-x="concept-appcache-fallback-ns">fallback namespace</span> must not be listed more
   than once.</p>
@@ -82147,6 +82149,13 @@ NETWORK:
    <li><p>Let <var>base URL</var> be the <span>absolute URL</span> representing the
    manifest.</p></li>
 
+   <li><p>Apply the <span>URL parser</span> to <var>base URL</var>, and let <var>manifest path</var>
+   be the <span data-x="concept-url-path">path</span> component thus obtained.</p></li>
+
+   <li><p>Remove all the characters in <var>manifest path</var> after the last U+002F SOLIDUS
+   character (/), if any. (The first character and the last character in <var>manifest path</var>
+   after this step will both be slashes, the URL path separator character.)</p></li>
+
    <li><p>Apply the <span>URL parser</span> steps to the <var>base URL</var>, so that the
    components from its <span>parsed URL</span> can be used by the subseqent steps of this
    algorithm.</p></li>
@@ -82301,6 +82310,13 @@ NETWORK:
       <p>If the <span>absolute URL</span> corresponding to either <var>part one</var> or
       <var>part two</var> does not have the <span>same origin</span> as the manifest's URL,
       then jump back to the step labeled <i>start of line</i>.</p> <!-- SECURITY -->
+
+      <p>Let <var>part one path</var> be the <span data-x="concept-url-path">path</span> component
+      of the <span>resulting parsed URL</span> for <var>part one</var>.</p>
+
+      <p>If <var>manifest path</var> is not a <span>prefix match</span> for <var>part one
+      path</var>, then jump back to the step labeled <i>start of line</i>.</p> <!-- SECURITY (in
+      depth) -->
 <!--REMOVE-TOPIC:Security-->
 
       <p>Let <var>part one</var> be the result of applying the <span
@@ -83336,6 +83352,38 @@ NETWORK:
   </div>
 
 
+<!--ADD-TOPIC:Security-->
+  <h4>Security concerns with offline applications caches</h4>
+
+  <!-- NON-NORMATIVE SECTION -->
+
+  <p>The main risk introduced by offline application caches is that an injection attack can be
+  elevated into persistent site-wide page replacement. This attack involves using an injection
+  vulnerability to upload two files to the victim site. The first file is an application cache
+  manifest consisting of just a fallback entry pointing to the second file, which is an HTML page
+  whose manifest is declared as that first file. Once the user has been directed to that second
+  file, all subsequent accesses to any file covered by the given fallback namespace while either the
+  user or the site is offline will instead show that second file. Targetted denial-of-service
+  attacks can be used to ensure that the site appears offline.</p>
+
+  <p>To mitigate this, manifests can only specify fallbacks that are in the same path as the
+  manifest itself. This means that a content injection upload vulnerability in a particular
+  directory on a server can only be escalated to a take-over of that directory and its
+  subdirectories. If there is no way to inject a file into the root directory, the entire site
+  cannot be taken over.</p>
+
+  <p>If a site has been attacked in this way, simply removing the offending manifest will eventually
+  clear the problem, since the next time the manifest is updated, a 404 error will be seen, and the
+  user agent will clear the cache. "Eventually" is the key word here, however; while the attack on
+  the user or server is ongoing, such that connections from an affected user to the affected site
+  are blocked, the user agent will simply assume that the user is offline and will continue to use
+  the hostile manifest.</p>
+
+  <p>TLS does not inherently protect a site from this attack, since the attack relies on content
+  being served from the server itself. Not using application caches also does not prevent this
+  attack, since the attack relies on an attacker-provided manifest.</p>
+<!--REMOVE-TOPIC:Security-->
+
 
   <h4>Application cache API</h4>