[html5] r8823 - [e] (0) Mention cookie-bombing in the appcache section Affected topics: Offline [...]

[whatwg at whatwg.org]

Author: ianh
Date: 2014-09-26 16:44:19 -0700 (Fri, 26 Sep 2014)
New Revision: 8823

Modified:
   complete.html
   index
   source
Log:
[e] (0) Mention cookie-bombing in the appcache section
Affected topics: Offline Web Applications, Security

Modified: complete.html
===================================================================
--- complete.html	2014-09-26 18:13:08 UTC (rev 8822)
+++ complete.html	2014-09-26 23:44:19 UTC (rev 8823)
@@ -62174,7 +62174,8 @@
   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
@@ -62182,12 +62183,14 @@
   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

Modified: index
===================================================================
--- index	2014-09-26 18:13:08 UTC (rev 8822)
+++ index	2014-09-26 23:44:19 UTC (rev 8823)
@@ -62174,7 +62174,8 @@
   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
@@ -62182,12 +62183,14 @@
   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

Modified: source
===================================================================
--- source	2014-09-26 18:13:08 UTC (rev 8822)
+++ source	2014-09-26 23:44:19 UTC (rev 8823)
@@ -84016,7 +84016,8 @@
   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
@@ -84024,12 +84025,14 @@
   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