OWASP ModSecurity Securing WebGoat Section4 Sublesson 04.4 04.5

4. Authentication Flaws

4.4 Multi Level Login 1

4.5 Multi Level Login 2

Lesson overview

See [relative paths].

Lesson solution

See [relative paths].

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'.