OWASP ModSecurity Securing WebGoat Section4 Sublesson 03.5 - Revision history

Stephen Evans: /* Strategy */

2008-10-29T13:04:51Z

‎Strategy

Stephen Evans: /* Strategy */

2008-10-29T13:02:46Z

‎Strategy

Stephen Evans: /* Strategy */

2008-10-29T12:59:17Z

‎Strategy

Stephen Evans at 07:50, 21 October 2008

2008-10-21T07:50:43Z

Stephen Evans at 05:28, 20 October 2008

2008-10-20T05:28:36Z

Stephen Evans at 05:28, 20 October 2008

2008-10-20T05:28:10Z

Stephen Evans at 05:24, 20 October 2008

2008-10-20T05:24:49Z

Stephen Evans: New page: 3. AJAX Security -> 3.5 XML Injection === Lesson overview === Refer to the zip file with the WebGoat lesson overviews. See Appendix A for more information. === Lesson solution === Ref...

2008-10-20T05:17:44Z

New page: 3. AJAX Security -> 3.5 XML Injection === Lesson overview === Refer to the zip file with the WebGoat lesson overviews. See Appendix A for more information. === Lesson solution === Ref...

New page

3. AJAX Security -> 3.5 XML Injection

=== Lesson overview ===

Refer to the zip file with the WebGoat lesson overviews. See Appendix A for more information.

=== Lesson solution ===

Refer to the zip file with the WebGoat lesson solutions. See Appendix A for more information.

=== Strategy ===

This WebGoat lesson adds more rewards to the allowed set of rewards by intercepting an AJAX response and appending these 2 entries to the XML list:
<pre>
<reward>WebGoat Core Duo Laptop 2000 Pts</reward>
<reward>WebGoat Hawaii Cruise 3000 Pts</reward>
</pre>

The lesson is broke on the back end:

When rewards are selected, a POST is sent, for example:
<font face="Courier New">accountID=836239&check1001=on&check1002=on&check1003=on&SUBMIT=Submit</font>

The problem is that there is no association between a checked entry, e.g. 'check1001' and a reward. This is because in the callback routine of the Ajax request, numbers are assigned irrespective of the reward:
<pre>
for(var i=0; i< rewards.length; i++){
strHTML = strHTML + '<tr><td><input name="check' + (i+1001) +'" type="checkbox">
</pre>

To prove it, I did not add the 2 high-priced point rewards, I substituted them for the 't-shirt 50 Pts' and 'Secure Kettle 30 pts'; the return message should be:

The following items will be shipped to your address:
</pre>
WebGoat Core Duo Laptop
WebGoat Hawaii Cruise
WebGoat Mug
</pre>

But the return message was erroneous:

[[Image:OWASP_ModSecurity_Securing_WebGoat_XML_Injection_SS0.jpg]]
(screenshot lesson03-5_rewards.jpg)

Therefore, since the rewards cannot be distinguished from each other, the only choice is to count the number of rewards sent, and if that doesn't match the number of rewards in the original HTTP response - before manipulation in the web proxy - then an error is thrown.

=== Implementation ===

The

=== Comments ===

The

← Older revision		Revision as of 13:04, 29 October 2008
Line 42:		Line 42:

	[[Image:OWASP_ModSecurity_Securing_WebGoat_XML_Injection_SS0.jpg]]		[[Image:OWASP_ModSecurity_Securing_WebGoat_XML_Injection_SS0.jpg]]
−
−	~~(screenshot lesson03-5_rewards.jpg)~~

@@ Line 17: / Line 17: @@
 </pre>
-However, the lesson is broke on the back end:
+However, the lesson is broke on the back end.
 When rewards are selected, a POST is sent, for example:

@@ Line 32: / Line 32: @@
 To prove it, I did not add the 2 high-priced point rewards, I substituted them for the 't-shirt 50 Pts' and 'Secure Kettle 30 pts'; the return message should be:
 The following items will be shipped to your address:
 WebGoat Core Duo Laptop
 WebGoat Hawaii Cruise

@@ Line 3: / Line 3: @@
 === Lesson overview ===
-Refer to the zip file with the WebGoat lesson overviews. See Appendix A for more information.
+The WebGoat lesson overview is included with the WebGoat lesson solution.
 === Lesson solution ===

@@ Line 90: / Line 90: @@
 For phase 2, the POST request parameters have the form:
 <pre>
-accountID=836239&check1001=on&check1002=on&check1003=on&SUBMIT=Submit</font>
+accountID=836239&check1001=on&check1002=on&check1003=on&SUBMIT=Submit
 </pre>

@@ Line 20: / Line 20: @@
 When rewards are selected, a POST is sent, for example:
+<pre>
-<font face="Courier New">accountID=836239&check1001=on&check1002=on&check1003=on&SUBMIT=Submit</font>
+accountID=836239&check1001=on&check1002=on&check1003=on&SUBMIT=Submit
 The problem is that there is no association between a checked entry, e.g. 'check1001' and a reward. This is because in the callback routine of the Ajax request, numbers are assigned irrespective of the reward:
@@ Line 43: / Line 44: @@
 (screenshot lesson03-5_rewards.jpg)
 Therefore, since the rewards cannot be distinguished from each other, the only choice is to count the number of rewards sent, and if that doesn't match the number of rewards in the original HTTP response - before manipulation in the web proxy - then an error is thrown.
@@ Line 87: / Line 89: @@
 For phase 2, the POST request parameters have the form:
+<pre>
-<font face="Courier New">accountID=836239&check1001=on&check1002=on&check1003=on&SUBMIT=Submit</font>
+accountID=836239&check1001=on&check1002=on&check1003=on&SUBMIT=Submit</font>
 The phase 2 request portion of the configuration file is:

@@ Line 17: / Line 17: @@
 </pre>
-The lesson is broke on the back end:
+However, the lesson is broke on the back end:
 When rewards are selected, a POST is sent, for example:
 <font face="Courier New">accountID=836239&check1001=on&check1002=on&check1003=on&SUBMIT=Submit</font>
@@ Line 31: / Line 32: @@
 The following items will be shipped to your address:
-</pre>
+<pre>
 WebGoat Core Duo Laptop
 WebGoat Hawaii Cruise
@@ Line 40: / Line 41: @@
 [[Image:OWASP_ModSecurity_Securing_WebGoat_XML_Injection_SS0.jpg]]
 (screenshot lesson03-5_rewards.jpg)
@@ Line 46: / Line 48: @@
 === Implementation ===
-The
+The ModSecurity solution will be to count the number of rewards sent to the user in the response body, then compare that with the number of rewards that the user subsequently sends in the request.
 === Comments ===
-The
+* This lesson shows how to use a 'do' loop in Lua and retrieve POST parameter names and values