OWASP ModSecurity Securing WebGoat Section4 Sublesson 06.1

6. Code Quality -> 6.1  Discover Clues in the HTML

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
The solution to this lesson is not to allow any admin or login credentials that have been placed in HTML comments to reach the user.

The guilty code is:

Implementation
The lesson is mitigated by the ruleset 'rulefile_06_code-quality.conf':

SecRule TX:MENU "!@eq 700" "phase:4,t:none,pass,skip:2"

SecRule RESPONSE_BODY \ "" \    "phase:4,t:none,log,auditlog,deny,severity:3,msg:'Authentication Credentials \     in HTML comment',id:'61',tag:'LEAKAGE',redirect:/_error_pages_/lesson06-1.html"

SecAction "phase:4,allow,t:none, \    msg:'Returning; nothing bad on this page (rulefile_06-1).'"

Notice that the 'TX:MENU' variable, which is set in the rulefile_00_initialize.conf, is used because using 'ARGS:menu' will not be accurate as it goes out of scope when leaving Phase 2.

Comment
The regex used for this solution can give false positives. It is okay for this lesson, but in 'Lesson 4.2 Authentication Flaws -> Forgot Password', this string of text also matches:

... Users can retrieve their password if they can answer the secret question properly. ...

The regex works as intended both in The Regex Coach and in Expresso. Instead of going through a laborious process each attempt just to see if the regex works as intended, it would be nice to have a utility that calls the exact same PCRE API that ModSecurity currently calls (see the source code file 'msc_util.c') so that the regex can be tested completely outside of ModSecurity.