OWASP ModSecurity Securing WebGoat Section4 Sublesson 01.2 - Revision history

Stephen Evans: /* Reviewer comments */

2008-10-29T12:04:21Z

‎Reviewer comments

Stephen Evans: added reviewer comments

2008-10-21T09:00:58Z

added reviewer comments

Stephen Evans at 06:32, 21 October 2008

2008-10-21T06:32:39Z

Stephen Evans: /* Lesson overview */

2008-10-20T03:15:40Z

‎Lesson overview

Stephen Evans at 03:14, 20 October 2008

2008-10-20T03:14:44Z

Stephen Evans at 11:58, 24 July 2008

2008-07-24T11:58:54Z

Stephen Evans: /* Strategy */

2008-07-24T11:05:26Z

‎Strategy

Stephen Evans: /* Implementation */

2008-07-24T11:03:52Z

‎Implementation

Stephen Evans: add content

2008-07-24T10:58:50Z

add content

New page

=== Lesson overview ===

See [relative path].

=== Lesson solution ===

See [relative path].

=== Strategy ===

The solution is to prevent carriage returns and line feeds from passing through. ModSecurity ruleset 'modsecurity_crs_40_generic_attacks.conf' already has some rules for an HTTP response splitting attack so they were used. In the second rule, note the transformations urlDecodeUni and htmlEntityDecode.

=== Implementation ===

The lesson is mitigated by the ruleset 'rulefile_01_general_http-splitting.conf':

<pre>
# The first rule is not necessary to solve the WebGoat lesson
SecRule REQUEST_URI|REQUEST_HEADERS|REQUEST_HEADERS_NAMES "%0[ad]" \
"t:lowercase,capture,log,auditlog,deny,severity:3, \
msg:'HTTP Response Splitting Attack via URI/Header',logdata:'%{TX.0}', \
tag:'HTTP_SPLITTING',redirect:/_error_pages_/lesson01a.html"

SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|XML:/* "(?:\bhttp\/(?:0\.9|1\.[01])|<(?:html|meta)\b)" \
"t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,capture,log,auditlog,deny, \
severity:3,msg:'HTTP Response Splitting Attack via args/file name', \
logdata:'%{TX.0}',tag:'HTTP_SPLITTING',redirect:/_error_pages_/lesson01b.html"
</pre>

← Older revision		Revision as of 12:04, 29 October 2008
Line 39:		Line 39:
	This may not be the best option from a performance perspective, but it will help to identify attacks as we would be inspecting the data both before and after each trans function is applied vs. the normal process of only inspecting it after all of them are completed.		This may not be the best option from a performance perspective, but it will help to identify attacks as we would be inspecting the data both before and after each trans function is applied vs. the normal process of only inspecting it after all of them are completed.

−	~~Also as I believe you mentioned in a recent modsecurity-users mail-list post, but~~ I have also seen web apps that allow clients to submit html. Oftentimes they use %0A and %0D to actually format html and not necessarily for HTTP Response Splitting attacks. We would need a different parser or something a bit more granular for this (Anti-Samy-ish).	+	I have also seen web apps that allow clients to submit html. Oftentimes they use %0A and %0D to actually format html and not necessarily for HTTP Response Splitting attacks. We would need a different parser or something a bit more granular for this (Anti-Samy-ish).

← Older revision		Revision as of 09:00, 21 October 2008
Line 30:		Line 30:
	logdata:'%{TX.0}',tag:'HTTP_SPLITTING',redirect:/_error_pages_/lesson01b.html"		logdata:'%{TX.0}',tag:'HTTP_SPLITTING',redirect:/_error_pages_/lesson01b.html"
	</pre>		</pre>
		+
		+	=== Reviewer comments ===
		+
		+	The Strategy/Implementation details look fine as you are using our existing Core Rule IDs 950910/950911. The only issue that I would raise, and it is not specific to this particular issue, is that of anti-evasion considerations when choosing the ModSecurity transformation functions to use. As you are all aware, the bad guys are constantly trying to bypass these types of filters by messing with encodings, whitespace formatting, etc… With this in mind, we may need to rethink and retest the applied trans functions. Ivan has been doing some research in this area and can provide more details and recommendations.
		+
		+	One item that I would suggest that you test is that of adding the ModSecurity multiMatch action - http://www.modsecurity.org/documentation/modsecurity-apache/2.5.5/modsecurity2-apache-reference.html#N11554.
		+
		+	This may not be the best option from a performance perspective, but it will help to identify attacks as we would be inspecting the data both before and after each trans function is applied vs. the normal process of only inspecting it after all of them are completed.
		+
		+	Also as I believe you mentioned in a recent modsecurity-users mail-list post, but I have also seen web apps that allow clients to submit html. Oftentimes they use %0A and %0D to actually format html and not necessarily for HTTP Response Splitting attacks. We would need a different parser or something a bit more granular for this (Anti-Samy-ish).

@@ 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 ===

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

← Older revision		Revision as of 11:58, 24 July 2008
Line 1:		Line 1:
		+	1. General
		+
		+	1.2 HTTP Splitting
		+
		+
	=== Lesson overview ===		=== Lesson overview ===

@@ Line 1: / Line 1: @@
-. General
+. General -> 1.2  HTTP Splitting
 === Lesson overview ===
-See [relative path].
+Refer to the zip file with the WebGoat lesson solution. See Appendix A for more information.
 === Lesson solution ===
-See [relative path].
+Refer to the zip file with the WebGoat lesson solutions. See Appendix A for more information.
 === Strategy ===

@@ Line 9: / Line 9: @@
 === Strategy ===
-The solution is to prevent carriage returns and line feeds from passing through. ModSecurity ruleset 'modsecurity_crs_40_generic_attacks.conf' already has some rules for an HTTP response splitting attack so they were used. In the second rule, note the transformations  urlDecodeUni and htmlEntityDecode.
+The solution is to prevent carriage returns and line feeds from passing through. ModSecurity ruleset 'modsecurity_crs_40_generic_attacks.conf' already has some rules for an HTTP response splitting attack so they were used. In the second rule, note the transformations <font face="Courier New">urlDecodeUni</font> and <font face="Courier New">htmlEntityDecode</font>.
 === Implementation ===

@@ Line 1: / Line 1: @@
 === Lesson overview ===
@@ Line 23: / Line 22: @@
 tag:'HTTP_SPLITTING',redirect:/_error_pages_/lesson01a.html"
-SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|XML:/* "(?:\bhttp\/(?:0\.9|1\.[01])|<(?:html|meta)\b)" \
+SecRule REQUEST_FILENAME|ARGS|ARGS_NAMES|XML:/* \
 	"t:urlDecodeUni,t:htmlEntityDecode,t:lowercase,capture,log,auditlog,deny, \
 severity:3,msg:'HTTP Response Splitting Attack via args/file name', \
 logdata:'%{TX.0}',tag:'HTTP_SPLITTING',redirect:/_error_pages_/lesson01b.html"
 </pre>