Section 4: Mitigating the WebGoat lessons

Project metrics

See Section 2 for the WebGoat lesson Table of Contents, and an overview of the results from doing the WebGoat lessons. Appendix A contains a zip file which is made up of the lesson plans and solutions - in HTML format - which were taken from WebGoat and can be viewed stand-alone.

Out of 51 possible lessons, the following are teaching lessons, not vulnerabilities, and therefore have no context for ModSecurity rules:

• 1.1 Http Basics
• 4.1 Password Strength
• 15.3 Bypass Client Side JavaScript Validation
• 17.1 Create a SOAP Request

Therefore there is a total number of 47 lessons to do; half is 24 so that was the goal of the first 50% of project completion. The lowest hanging fruit was taken first because considerable effort was put into: (1) setup and configuration of the environment; (2) getting familiar with WebGoat and taking all of the lessons; (3) learning ModSecurity (and Remo); (4) re-learning regular expressions; (5) learning Lua script; and (6) developing an efficient work methodology.

The total number of sublessons mitigated by ModSecurity rules: 25 - thereby achieving the goal of at least 50% of sublessons mitigated.

They are:

• Sublesson 1.2
• Sublesson 2.4
• Sublessons 4.2, 4.4, 4.5
• Sublesson 6.1
• Sublessons 8.1, 8.2, 8.4, 8.5, 8.7
• Sublesson 10.1
• Sublessons 11.1, 11.2, 11.3, 11.4, 11.5, 11.6, 11.7, 11.8
• Sublesson 13.1
• Sublessons 15.1, 15.2
• Sublessons 17.3, 17.4

Overall strategy

4.2 Overall strategy

The intention of mitigating the vulnerabilities is to demonstrate the largest variety of mitigating solutions and features of ModSecurity as possible: - Some lessons are solved using the easiest way possible for convenience (and to count towards achieving the goal of 50% complete!) - Some lessons are solved by using rules from the core rulesets provided by Breach Security - Some mitigating solutions are meant to be global, meaning being in effect at all times, like the XSS and Command Injection core rules from Breach Security - One lesson demonstrates the use of a session variable - Some lessons require persistence beyond what is offered by ModSecurity; Lua scripts are used to achieve this - Some lessons require a more robust capability than ModSecurity's regular expressions, 'and/or' logical mechanisms, and goto statements (skip and skipAfter); again, Lua scripts are used to achieve this. - One lesson uses the 'append' action to append Javascript to the end of a response body, which alters the content and behavior of the HTML page

The rulesets can be used all together or, for a specific WebGoat sublesson, the initialization file (rulefile_00_initialize.conf) plus that sublesson's ruleset can be used.

The best way to open the discussion about the overall strategy used is to show a chunk of the initialization file:

<LocationMatch "^/WebGoat/attack$">
  # Group 1: the following block pertain to pages that don't have 
  #   Screen or menu parameters
1.  SecRule &ARGS:Screen "!@eq 0" chain,skipAfter:200
2.  SecRule &ARGS:menu "!@eq 0" "t:none"

  # Group 2: set session collection if entering WebGoat; POST body parameter 
  #   is "start=Start WebGoat" (Start WebGoat submit button)
3.  SecRule &ARGS_POST:start "@eq 0" "nolog,skip:3"
4.  SecRule ARGS_POST:start "!@streq Start WebGoat" \ 
      "t:urlDecodeUni,t:htmlEntityDecode,skip:2"
5.  SecRule REQUEST_COOKIES:JSESSIONID "!^$" \ 
      "chain,log,auditlog,pass,msg:'Setting session collection'"
6.  SecAction setsid:%{REQUEST_COOKIES.JSESSIONID} 
7.  SecAction "log,setvar:session.lesson13=0,msg:'setting session.lesson13=0 \  
      initially after setsid from rulefile_00-0-initialize.conf'"

8.  SecAction "t:none,allow,id:'200'"

  # Group 3: here there should be a 'menu' parameter, so set a variable for          
  #   the menu number that's used if needed in Phase 4
9.  SecRule ARGS_GET:menu "^(.*)$" "pass,setvar:tx.menu=%{MATCHED_VAR}"