OWASP ModSecurity Securing WebGoat Section4 Sublesson 06.1 - Revision history

Stephen Evans at 09:55, 13 November 2008

2008-11-13T09:55:10Z

Stephen Evans: /* Reviewer comments */

2008-11-01T03:31:59Z

‎Reviewer comments

Stephen Evans: add Reviewer comments section

2008-10-21T10:43:10Z

add Reviewer comments section

Stephen Evans at 07:57, 21 October 2008

2008-10-21T07:57:25Z

Stephen Evans: /* Comment */

2008-07-24T15:00:02Z

‎Comment

Stephen Evans at 14:58, 24 July 2008

2008-07-24T14:58:35Z

Stephen Evans: add content

2008-07-24T14:55:06Z

add content

New page

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:

<pre>

</pre>

=== Implementation ===

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

<pre>
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).'"
</pre>

Notice that the <font face="Courier New">'TX:MENU'</font> variable, which is set in the rulefile_00_initialize.conf, is used because using <font face="Courier New">'ARGS:menu'</font> 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:

<pre>

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

</pre>

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.

@@ Line 40: / Line 40: @@
 Notice that the <font face="Courier New">'TX:MENU'</font> variable, which is set in the rulefile_00_initialize.conf, is used because using <font face="Courier New">'ARGS:menu'</font> will not be accurate as it goes out of scope when leaving Phase 2.
-=== Comment ===
+=== Comments ===
 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:
@@ Line 66: / Line 66: @@
-The best option that I see is to actually remove all comments from outbound data, however seeing as ModSecurity cannot currently do this then the next best thing is to alert and/or block.  In order to make our RegEx more generic and to look for other comment formats we should account for C-style, Javascript and one-liner comments:
+The best option that I see is to actually remove all comments from outbound data, however seeing as ModSecurity cannot currently do this then the next best thing is to alert and/or block.  In order to make our RegEx more generic and to look for other comment formats we should account for C-style, JavaScript and one-liner comments:
 C-style:
@@ Line 78: / Line 78: @@
 </pre>
-Javascript/C++ style:
+JavaScript/C++ style:
 <pre>

@@ Line 59: / Line 59: @@
 Information leakage through html comments is an interesting challenge from a WAF perspective.  Here are a few of them:
-. No False Negatives – we don't want to miss any comments so we need to have an accurate html parser in order to deal with all possible formats, etc…  Something like mod_html_proxy or mod_publisher would help in this area.
+. No False Negatives: We don't want to miss any comments so we need to have an accurate html parser in order to deal with all possible formats, etc…  Something like mod_html_proxy or mod_publisher would help in this area.
-. All Comments != Bad – HTML comments, in and of themselves, are not bad.  It is only the ones that are leaking sensitive info.  The question is what is sensitive?  In the context of this WebGoat lesson, the sensitive info is the admin credentials.  Unfortunately, if we try to address the underlying issue and not just for this lesson, we have no idea of the exact format of the data being presented.
+. All Comments != Bad: HTML comments, in and of themselves, are not bad.  It is only the ones that are leaking sensitive info.  The question is what is sensitive?  In the context of this WebGoat lesson, the sensitive info is the admin credentials.  Unfortunately, if we try to address the underlying issue and not just for this lesson, we have no idea of the exact format of the data being presented.
-. Blocking vs. Scrubbing – Assuming we can reliably detect comments but not necessarily any sensitive data leaks, is this category of issue severe enough that you would want to block the entire response?  Scrubbing inbound data for attacks and sending it onto the application is more risky than scrubbing outbound data for info leakages and then sending it onto clients.  Once again, a module such as mod_proxy_html even has a remove comments directive that will handle this issue.
+. Blocking vs. Scrubbing: Assuming we can reliably detect comments but not necessarily any sensitive data leaks, is this category of issue severe enough that you would want to block the entire response?  Scrubbing inbound data for attacks and sending it onto the application is more risky than scrubbing outbound data for info leakages and then sending it onto clients.  Once again, a module such as mod_proxy_html even has a remove comments directive that will handle this issue.
 The best option that I see is to actually remove all comments from outbound data, however seeing as ModSecurity cannot currently do this then the next best thing is to alert and/or block.  In order to make our RegEx more generic and to look for other comment formats we should account for C-style, Javascript and one-liner comments:
-C-style –
+C-style:
 <pre>
@@ Line 78: / Line 78: @@
 </pre>
-Javascript/C++ style –
+Javascript/C++ style:
 <pre>
@@ Line 84: / Line 84: @@
 </pre>
-Also a one-liner with just the beginning –
+Also a one-liner with just the beginning:
 <pre>

@@ Line 44: / Line 44: @@
 === 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:
+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:
 <pre>
@@ Line 55: / Line 55: @@
-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 utiliy 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.
+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.

@@ Line 1: / Line 1: @@
 .  Code Quality
@@ Line 23: / Line 22: @@
    -->
 </pre>
 === Implementation ===
@@ Line 57: / Line 55: @@
-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.
+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 utiliy 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.

@@ Line 16: / Line 16: @@
 <pre>
-<!--
+<!-- 	FIXME admin:adminpw
    -->
 </pre>
@@ Line 30: / Line 29: @@
    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 \
+     "phase:4,t:none,log,auditlog,deny,severity:3, \
-    in HTML comment',id:'61',tag:'LEAKAGE',redirect:/_error_pages_/lesson06-1.html"
+msg:'Authentication Credentials in HTML comment',id:'61',tag:'LEAKAGE', \
    SecAction "phase:4,allow,t:none, \
@@ Line 54: / Line 54: @@
 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.

@@ Line 1: / Line 1: @@
-.  Code Quality
+.  Code Quality -> 6.1  Discover Clues in the HTML
 === Lesson overview ===
-See [relative path].
+The WebGoat lesson overview is included with the WebGoat lesson solution.
 === Lesson solution ===
-See [relative path].
+Refer to the zip file with the WebGoat lesson solutions. See Appendix A for more information.
 === Strategy ===