Standardized all the HTML, clarified things, and fixed a whole bunch of grammar issues.

I also changed the explanation for Browser Cache Poisoning; the old explanation was incorrect.  If I'm mistaken on that, feel free to revert that part of the explanation.


git-svn-id: http://webgoat.googlecode.com/svn/trunk@369 4033779f-a91e-0410-96ef-6bf7bf53c507

webgoat/main/project/WebContent/lesson_plans/HttpSplitting.html

@@ -1,32 +1,34 @@
 <div align="Center"> 
-<p><b>Lesson Plan Title:</b> How to Perform Http Splitting </p>
+<p><b>Lesson Plan Title:</b> How to Perform HTTP Splitting </p>
  </div>
  
 <p><b>Concept / Topic To Teach:</b> </p>
  This lesson teaches how to perform HTTP Splitting attacks.
- <br> 
+ <br /> 
 <div align="Left"> 
 <p>
-<b>How the attacks works:</b>
+<b>How the attack works:</b>
 </p>
-The attacker passes malicious code to the web server together with normal input. 
+<p>The attacker passes malicious code to the web server together with normal input. 
 A victim application will not be checking for CR (carriage return, also given by %0d or \r) 
-and LF (line feed, also given by %0a or \n)characters. These characters not only give attackers control 
+and LF (line feed, also given by %0a or \n) characters. These characters not only give attackers control 
 of the remaining headers and body of the response the application intends to send, 
-but also allows them to create additional responses entirely under their control.<br>
+but they also allows them to create additional responses entirely under their control.</p>
-The effect of an HTTP Splitting attack is maximized when accompanied with a Cache Poisoning. The goal of
+<p>The effect of an HTTP Splitting attack is maximized when accompanied with a Cache Poisoning. The goal of
-Cache Poisoning attack is to poison the cache of the victim by fooling the cache to believe that the page
+Cache Poisoning attack is to poison the cache of the victim by fooling the cache into believing that the page
-hijacked using the HTTP splitting is a good one and it is indeed the server's copy.<br>
+hijacked using the HTTP splitting is an authentic version of the server's copy.</p>
-The attack happens using the HTTP Splitting attack plus adding the <b>Last-Modified:</b> header and setting it
+<p>The attack works by using the HTTP Splitting attack plus adding the <b>Last-Modified:</b> header and setting it
-to a future date. This will force the browser to send <b>If-Modified-Since</b> request header, which gives the attacker
+to a future date. This forces the browser to send an incorrect <b>If-Modified-Since</b> request header on future requests.
-the chance to intercept the server's reply and replace it with a '304 Not Modified' reply. A sample of a 304 response is:<br>
+Because of this, the server will always report that the (poisoned) page has not changed, and the victim's browser
-HTTP/1.1 304 Not Modified <br>
+will continue to display the attacked version of the page.</p>
-Date: Fri, 30 Dec 2005 17:32:47 GMT
+<p>A sample of a 304 response is:
-
+<blockquote>HTTP/1.1 304 Not Modified <br />
+Date: Fri, 30 Dec 2005 17:32:47 GMT</blockquote>
+</p>
 </div>
 <p><b>General Goal(s):</b> </p>
 <!-- Start Instructions -->
-This lesson has two stages. Stage 1 teaches you how to do HTTP Splitting attacks while stage 2 builds on that to teach you how to elevate HTTP Splitting to Cache Poisoning.<br>
+<p>This lesson has two stages. Stage 1 teaches you how to do HTTP Splitting attacks while stage 2 builds on that to teach you how to elevate HTTP Splitting to Cache Poisoning.</p>
-Enter a language for the system to search by. You will notice that the application is redirecting your request to another resource on the server. You should be able to use the CR (%0d) and LF (%0a) to exploit the attack. Your exercise should be to force the server to send a 200 OK. If the screen changed as an effect to your attack, just go back to the homepage and after stage 2 is exploited successfully you will find the green check in the left menu.
+<p>Enter a language for the system to search by. You will notice that the application is redirecting your request to another resource on the server. You should be able to use the CR (%0d) and LF (%0a) characters to exploit the attack. Your goal should be to force the server to send a 200 OK. If the screen changed as an effect to your attack, just go back to the homepage. After stage 2 is exploited successfully, you will find the green check in the left menu.</p>
 <!-- Stop Instructions -->