This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP ModSecurity Securing WebGoat Section4 Sublesson 04.4 04.5"

From OWASP
Jump to: navigation, search
Line 1: Line 1:
 +
4.  Authentication Flaws -> 4.4  Multi Level Login 1
 +
4.  Authentication Flaws -> 4.5  Multi Level Login 2
  
4. Authentication Flaws
+
The lessons are combined because the strategy and the ruleset to solve them are the same.  
 
 
4.4  Multi Level Login 1
 
 
 
4.5  Multi Level Login 2
 
  
 
=== Lesson overview ===
 
=== Lesson overview ===
  
See [relative paths].
+
The WebGoat lesson overview is included with the WebGoat lesson solution.
  
 
=== Lesson solution ===  
 
=== Lesson solution ===  
  
See [relative paths].
+
Refer to the zip file with the WebGoat lesson solutions. See Appendix A for more information.
  
 
=== Strategy ===  
 
=== Strategy ===  

Revision as of 04:42, 21 October 2008

4. Authentication Flaws -> 4.4 Multi Level Login 1 4. Authentication Flaws -> 4.5 Multi Level Login 2

The lessons are combined because the strategy and the ruleset to solve them are the same.

Lesson overview

The WebGoat lesson overview is included with the WebGoat lesson solution.

Lesson solution

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

Strategy

In both lessons, the attacker alters a value of a hidden field; for the first one it is: '<input name='hidden_tan' type='HIDDEN' value='2'>'

In order to solve this, the hidden field values have to be saved in the response body and then, when the request is sent, compared to see if it has been altered. It might be technically possible to use the session collection functionality of ModSecurity, parse the response body with a regular expression and store the hidden values, then do the same in the following request and make the comparison. Instead, Lua scripts are used; see Section 4.3 'Using the Lua scripting language' for details on how Lua is used to detect if input values - in this case hidden ones - have been altered on the client side.

Implementation

The lesson is mitigated in the ruleset 'rulefile_04_authentication-flaws.conf'.

  SecRule ARGS:menu "!@eq 500" "phase:2,t:none,skip:2"

  # following takes care of 4.3 & 4.4 - Multi Level Login
  # action is triggered if script returns non-nil value
  SecRuleScript "/etc/modsecurity/data/read-hidden-values_04.lua" \
    "phase:2,t:none,log,auditlog,deny,severity:3, \ 
    msg:'Parameter Tampering; Hidden field', \ 
    tag:'PARAMETER_TAMPERING',redirect:/_error_pages_/lesson04-4.html"
  SecAction "phase:2,allow:request,t:none,log,auditlog, \ 
    msg:'Luascript: hidden field not altered or does not exist'"

################################################################

  SecRule TX:MENU "!@eq 500" "phase:4,t:none,pass,skip:1"

  # parse response body and write hidden values to file
  SecRuleScript "/etc/modsecurity/data/write-hidden-values1.lua" \
    "phase:4,t:none,log,auditlog,allow,msg:'Writing RESPONSE BODY \ 
    & parsed input fields to file using luascript'"


Both rules are only processed only when in this lesson (menu=500).

The 2nd rule uses the lua script 'write-hidden-values1.lua' in Phase 4 to write HTML input element values to a data file from every response request, in this format:

Entry{
  name = "hidden_tan",
  type = "HIDDEN",
  value = "2"
}

Entry{
  name = "tan",
  type = "TEXT",
  value = ""
}

Entry{
  name = "Submit",
  type = "SUBMIT",
  value = "Submit"
}


For every request, the lua file 'read-hidden-values_04.lua' gets the hidden field value, 'hidden_tan', compares it with the value stored in the data file, and matches the SecRuleScript if the field has been altered.

The same solution is used for Multi Level Login 2, only in this case the hidden field name is 'hidden_user'.