OWASP ModSecurity Securing WebGoat Section4 Sublesson 16.2 - Revision history

Stephen Evans at 05:08, 1 November 2008

2008-11-01T05:08:48Z

Stephen Evans: /* Reviewer comments */

2008-10-27T11:02:54Z

‎Reviewer comments

Stephen Evans: added content

2008-10-27T11:02:24Z

added content

New page

16. Session Management Flaws -> 16.2 Spoof an Authentication Cookie

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

This WebGoat lesson shows how to guess another user's authentication cookie. The vulnerability is that the cookie is easy to guess even from only 2 unique user accounts and their authentication cookie; it is exploited by logging in as another user and supplying the predictable authentication cookie.

A ModSecurity solution is not possible for this lesson because it is not possible to distinguish between an authentication cookie that comes from a valid user versus one that comes from an attacker.

=== Implementation ===

None

=== Reviewer comments ===

For this particular lesson, it is possible to use mitigation #2 of 16.1:
2. The critical point in identifying Session Hijacking attacks is to bind the client IP (and possibly other browser data) to the SessionID when the webapp hands it out in the Set-Cookie response header. If this is done, you can then identify when someone guesses a SessionID and adds it to their browser as the REMOTE_ADDR variable data will not match what ModSecurity saved in the setsid Session collection when the app handed it out.

We know that the cookie is weak/easily guessed however what we will be enforcing is that the webapp did *NOT* give this out to the client in a Set-Cookie response header so it is not valid.

← Older revision		Revision as of 05:08, 1 November 2008
Line 1:		Line 1:
	16. Session Management Flaws -> 16.2 Spoof an Authentication Cookie		16. Session Management Flaws -> 16.2 Spoof an Authentication Cookie
		+
		+	(This sublesson was not formally solved by the project)

	=== Lesson overview ===		=== Lesson overview ===

@@ Line 21: / Line 21: @@
 === Reviewer comments ===
-For this particular lesson, it is possible to use mitigation #2 of 16.1:
+For this particular lesson, it is possible to use mitigation #2 of Sublesson 16.1:
 . The critical point in identifying Session Hijacking attacks is to bind the client IP (and possibly other browser data) to the SessionID when the webapp hands it out in the Set-Cookie response header.  If this is done, you can then identify when someone guesses a SessionID and adds it to their browser as the REMOTE_ADDR variable data will not match what ModSecurity saved in the setsid Session collection when the app handed it out.
 We know that the cookie is weak/easily guessed however what we will be enforcing is that the webapp did *NOT* give this out to the client in a Set-Cookie response header so it is not valid.