OWASP ModSecurity Securing WebGoat Section4 Sublesson 01.1 - Revision history

Stephen Evans: /* Strategy */

2008-11-13T09:12:56Z

‎Strategy

Stephen Evans: /* Strategy */

2008-11-13T09:11:41Z

‎Strategy

Stephen Evans: /* Strategy */

2008-10-29T11:25:10Z

‎Strategy

Stephen Evans: /* Strategy */

2008-10-29T11:13:33Z

‎Strategy

Stephen Evans at 07:46, 21 October 2008

2008-10-21T07:46:57Z

Stephen Evans at 03:34, 20 October 2008

2008-10-20T03:34:00Z

Stephen Evans: added content

2008-10-20T03:32:20Z

added content

Stephen Evans: create page

2008-10-20T03:19:35Z

create page

New page

1. Introduction -> 1.1 Http Basics

=== Lesson overview ===

Refer to the zip file with the WebGoat lesson overviews. See Appendix A for more information.

=== Lesson solution ===

Refer to the zip file with the WebGoat lesson solutions. See Appendix A for more information.

=== Strategy ===

The

=== Implementation ===

The

@@ Line 69: / Line 69: @@
 <pre>
 echo > modsec_debug.log
-/etc/init.d/apache2 restart #if you made changes to any ModSecurity files loaded at Apache startup
+/etc/init.d/apache2 restart #if you made changes to any ModSec config files
 </pre>

@@ Line 30: / Line 30: @@
 SecContentInjection On
 </pre>
-This directive is essential for the solutions that use Javascript injection ('prepend' or 'append') into the response body.
+This directive is essential for the solutions that use JavaScript injection ('prepend' or 'append') into the response body.
 <pre>
@@ Line 68: / Line 68: @@
 Every single bug or unwanted behavior can be discovered by setting the debug log file at Level 9. Instead of guessing what the problem is and messing around with other stuff, set this to 9 and reproduce the problem. If you spend any significant amount of time using ModSecurity, it is best to learn how to read the debug as quickly as possible. The debug file can get large quickly, so go to the step immediately before the problem, then do this from '/etc/modsecurity/logs' (an apology to Windows users):
 <pre>
-rm -f modsec_debug.log
+echo > modsec_debug.log
-touch modsec_debug.log
+/etc/init.d/apache2 restart #if you made changes to any ModSecurity files loaded at Apache startup
 </pre>
@@ Line 78: / Line 77: @@
 !11
 !12
 </pre>
 over and over and over.
@@ Line 89: / Line 87: @@
 <font><u>Some tips, learned from bad experiences and long hours</u></font>
-ModSecurity session collections and variables: A confusing aspect of ModSecurity persistence is when to use 'initcol' to load session collections and stored variables. It seems that it is not necessary when in the same phase or within the same ruleset file (with more than one phase), but necessary at all other times. The debug log explicitly states when a session collection is loaded; a missing 'initcol' will result in a message like 'Variable does not exist'.
+ModSecurity session collections and variables: A confusing aspect of ModSecurity persistence is when to use 'initcol' to load session collections and stored variables. It seems that it is not necessary when in the same phase or within the same ruleset file (with more than one phase), but necessary at all other times  [Note: This observation by the project member is presumably wrong; a reviewer stated that “‘initcol’ has to be execuated at least once, anywhere prior to the place where the collection is being used. Phases and rule location do not matter.”]. The debug log explicitly states when a session collection is loaded; a missing 'initcol' will result in a message like 'Variable does not exist'.
 Use of 'skip': When there are many ruleset files, using 'skipAfter' can potentially cause a problem if there are duplicate SecActions with the same 'id' number so in some cases it is preferable to use 'skip'. But, during development and debugging, or using 'chain', the 'skip' number can get out of alignment and jump over directives that should be processed. Again, going straight to the debug log set at level 9 and stepping through the expected ModSecurity directives one at a time will save a lot of time.
@@ Line 97: / Line 95: @@
 Use of 'allow': Mistakenly using 'allow' instead of 'allow:request' when it is intended to end processing of the request phase results can take eons to discover if one doesn't go straight to the debug log file; very clearly it will state something like "Skipping processing response phase"; the "Starting phase RESPONSE_BODY" message and the expected ModSecurity directives will not appear.
-The processing order of ruleset files: ModSecurity processes *.conf files in alphabetical order which is why the initialization file needed by all project lesson solutions is named 'rulefile_00_initialize.conf' and the lesson solutions follow the naming convention of 'rulefile_xx_*.conf' where 'xx' is the lesson number and '*' is a description of the sublesson. Using multiple solution files at the same time may cause unintended results.
+The processing order of ruleset files: Apache processes *.conf files in alphabetical order which is why the initialization file needed by all project lesson solutions is named 'rulefile_00_initialize.conf' and the lesson solutions follow the naming convention of 'rulefile_xx_*.conf' where 'xx' is the lesson number and '*' is a description of the sublesson [Reviewer note: “Explicitly listing the rules will determine the order that they will be processed.”]. Using multiple solution files at the same time may cause unintended results.
 The Apache 'LocationMatch' directive: When processing HTTP requests and WebGoat accesses files and directories outside of the normal '/WebGoat/attack' directory, be careful about the ordering of 'LocationMatch' when multiple ModSecurity configuration files are used. The symptom is that the intended configuration file will not be processed and it will not appear in the debug log file.

@@ Line 91: / Line 91: @@
 ModSecurity session collections and variables: A confusing aspect of ModSecurity persistence is when to use 'initcol' to load session collections and stored variables. It seems that it is not necessary when in the same phase or within the same ruleset file (with more than one phase), but necessary at all other times. The debug log explicitly states when a session collection is loaded; a missing 'initcol' will result in a message like 'Variable does not exist'.
-Use of 'skip': When there are many ruleset files, using skipAfter can potentially cause a problem if there are duplicate SecActions with the same 'id' number so in some cases it is preferable to use 'skip'. But, during development and debugging, or using 'chain', the 'skip' number can get out of alignment and jump over directives that should be processed. Again, going straight to the debug log set at level 9 and stepping through the expected ModSecurity directives one at a time will save a lot of time.
+Use of 'skip': When there are many ruleset files, using 'skipAfter' can potentially cause a problem if there are duplicate SecActions with the same 'id' number so in some cases it is preferable to use 'skip'. But, during development and debugging, or using 'chain', the 'skip' number can get out of alignment and jump over directives that should be processed. Again, going straight to the debug log set at level 9 and stepping through the expected ModSecurity directives one at a time will save a lot of time.
 Use of 'phase:4': Forgetting to use 'phase:4' in a directive when processing the HTTP response body will produce strange results because they will be processed in the default phase which is normally phase 2 the request phase.

@@ Line 11: / Line 11: @@
 === Strategy ===
-This lessons shows the basics of HTTP and the use of a web proxy to examine HTTP traffic.
+This lesson shows the basics of HTTP and the use of a web proxy to examine HTTP traffic.
 For a ModSecurity solution to this lesson, relevant ModSecurity configuration basics will be presented along with debugging tips and tricks. Performing this simple WebGoat lesson, one can experiment with the configuration directives, examine the debug log file, and be better prepared to implement the ModSecurity solutions in this project.

@@ Line 1: / Line 1: @@
-. General -> 1.1 Http Basics
+. General -> 1.1 HTTP Basics
 === Lesson overview ===
@@ Line 100: / Line 100: @@
 The Apache 'LocationMatch' directive: When processing HTTP requests and WebGoat accesses files and directories outside of the normal '/WebGoat/attack' directory, be careful about the ordering of 'LocationMatch' when multiple ModSecurity configuration files are used. The symptom is that the intended configuration file will not be processed and it will not appear in the debug log file.
 <font><u>Lua Debugging</u></font>

@@ Line 3: / Line 3: @@
 === Lesson overview ===
-Refer to the zip file with the WebGoat lesson overviews. See Appendix A for more information.
+The WebGoat lesson overview is included with the WebGoat lesson solution.
 === Lesson solution ===