OWASP ModSecurity Securing WebGoat Section4 Sublesson 06.1

6. Code Quality

6.1 Discover Clues in the HTML

Lesson overview

See [relative path].

Lesson solution

See [relative path].

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:

<!-- 
	FIXME admin:adminpw
  -->

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 \ 
    "<!--[ \r\n\t]*?(.*)?(?i:adm(in)?|pwd|passw(or)?d)(.*)?[ \r\n\t]*?-->" \ 
    "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's okay for this lesson, but in 'Lesson 4.2 Authentication Flaws -> Forgot Password', this string of text also matches:

<!-- Start Instructions -->
...
Users can retrieve their password if they can answer the secret question properly. 
...
<!-- Stop Instructions -->

The regex works as intended both in The Regex Coach and in Expresso. The project member believes that this is a current shortcoming of ModSecurity - going through a laborious process each attempt just to see if the regex works - until a tool is written 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.