[e] (0) Mention cookie-bombing in the appcache section

Affected topics: Offline Web Applications, Security git-svn-id: https://svn.whatwg.org/webapps@8823 340c8d12-0b0e-0410-8428-c7bf67bfef74
whatwg · Sep 26, 2014 · 2a46d9b · 2a46d9b
1 parent 00641cc
commit 2a46d9b
Show file tree

Hide file tree

Showing 3 changed files with 18 additions and 9 deletions.
diff --git a/complete.html b/complete.html
@@ -62174,20 +62174,23 @@ <h4 id=security-concerns-with-offline-applications-caches>7.7.9 Security concern
   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>
+  attacks or cookie bombing attacks (where the client is made to send so many cookies that the
+  server refuses to process the request) 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
+  <p>If a site has been attacked in this way, simply removing the offending manifest might 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>
+  the hostile manifest. Unfortunately, if a cookie bombing attack has also been used, merely
+  removing the manifest is insufficient; in addition, the server has to be configured to return a
+  404 or 410 response instead of the 413 "Request Entity Too Large" response.</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

diff --git a/index b/index
@@ -62174,20 +62174,23 @@ NETWORK:
   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>
+  attacks or cookie bombing attacks (where the client is made to send so many cookies that the
+  server refuses to process the request) 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
+  <p>If a site has been attacked in this way, simply removing the offending manifest might 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>
+  the hostile manifest. Unfortunately, if a cookie bombing attack has also been used, merely
+  removing the manifest is insufficient; in addition, the server has to be configured to return a
+  404 or 410 response instead of the 413 "Request Entity Too Large" response.</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

diff --git a/source b/source
@@ -84016,20 +84016,23 @@ NETWORK:
   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>
+  attacks or cookie bombing attacks (where the client is made to send so many cookies that the
+  server refuses to process the request) 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
+  <p>If a site has been attacked in this way, simply removing the offending manifest might 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>
+  the hostile manifest. Unfortunately, if a cookie bombing attack has also been used, merely
+  removing the manifest is insufficient; in addition, the server has to be configured to return a
+  404 or 410 response instead of the 413 "Request Entity Too Large" response.</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