Cache Poisoning - Revision history

Achim: advertising disabled

2014-11-04T19:19:36Z

advertising disabled

2014-11-04T19:18:14Z

note added

2014-11-04T19:17:51Z

2014-11-04T19:16:58Z

category changed from "Input Validation Attack" to "Input Validation"

2009-04-23T11:38:30Z

2009-04-07T23:33:29Z

2009-04-02T14:44:25Z

2009-02-17T01:48:47Z

2009-02-13T19:35:34Z

2009-02-13T19:34:20Z

‎Examples

@@ Line 1: / Line 1: @@
 {{Template:Attack}}
-{{Template:Fortify}}
+<!-- advertising disabled: {{Template:Fortify}} -->
 <br>

@@ Line 3: / Line 3: @@
 <br>
-Last revision (mm/dd/yy): '''04/23/2009''' <small>(please ''view source'')
+Last revision (mm/dd/yy): '''04/23/2009''' <small>(please ''view source'')</small>
 <!--
      Last revision hardcoded to 04/23/2009 on 04/Nov/2014 because:

@@ Line 3: / Line 3: @@
 <br>
-Last revision (mm/dd/yy): '''04/23/2009'''
+Last revision (mm/dd/yy): '''04/23/2009''' <small>(please ''view source'')
 <!--
      Last revision hardcoded to 04/23/2009 on 04/Nov/2014 because:

@@ Line 2: / Line 2: @@
 {{Template:Fortify}}
 <br>
 Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''
+-->
 ==Description==
 The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue to receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although only the user of the local browser instance will be affected.
@@ Line 126: / Line 130: @@
-[[Category:Input Validation Attack]]
+[[Category:Input Validation]]
 [[Category:Abuse of Functionality]]
 [[Category:Attack]]

@@ Line 3: / Line 3: @@
 <br>
 [[Category:OWASP ASDR Project]]
 ==Description==

@@ Line 68: / Line 68: @@
 Accept-Charset: iso-8859-1,*,utf-8
 </pre>
-We are intentionally setting the future time (presently it's 2007 but in the header it's set to 2009) in the second
+We are intentionally setting the future time (in the header it's set to 27 October 2009) in the second
 response HTTP header "Last-Modified" to store the response in the cache.
 [[Category:FIXME|need to update now that it's 2009]]

@@ Line 3: / Line 3: @@
 <br>
 [[Category:OWASP ASDR Project]]
-[[ASDR Table of Contents]]__TOC__
+[[ASDR Table of Contents]]
 ==Description==
 The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue to receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although only the user of the local browser instance will be affected.
@@ Line 24: / Line 23: @@
 ==Examples ==
 We have found a web page, which gets its service name from the "page" argument and then redirects (302)
 to this service.
@@ Line 110: / Line 108: @@
 ==Related [[Threat Agent]]s==
 * TBD
 ==Related [[Attacks]]==

@@ Line 95: / Line 95: @@
 method to be used), possibly immediately one after another.
-It may appear problematic to use this attack as universal techique for cache poisoning. It's due to cache server's different
+It may appear problematic to use this attack as a universal techique for cache poisoning. It's due to cache server's different
 connection model and request proccessing implementations. What does it mean? That for example effective method to poison
 Apache 2.x cache with mod_proxy and mod_cache modules won't work with Squid.