CSRFGuard 3 Configuration - Revision history

Esheridan: /* New Token Landing Page */

2011-02-12T17:47:59Z

‎New Token Landing Page

Esheridan: /* New Token Landing Page */

2010-12-22T22:32:00Z

‎New Token Landing Page

Esheridan: /* org.owasp.csrfguard.action.Log */

2010-12-22T15:22:21Z

‎org.owasp.csrfguard.action.Log

Esheridan at 22:51, 13 December 2010

2010-12-13T22:51:37Z

Esheridan: /* Actions: Responding to Attacks */

2010-12-13T22:45:12Z

‎Actions: Responding to Attacks

Esheridan: /* Referrer Checking */

2010-12-13T22:39:03Z

‎Referrer Checking

Esheridan: /* Ajax and XMLHttpRequest Support */

2010-12-13T22:36:41Z

‎Ajax and XMLHttpRequest Support

Esheridan at 22:21, 13 December 2010

2010-12-13T22:21:08Z

Esheridan: /* Referrer Checking */

2010-12-02T01:56:03Z

‎Referrer Checking

Esheridan: /* Ajax and XMLHttpRequest Support */

2010-12-02T01:54:26Z

‎Ajax and XMLHttpRequest Support

@@ Line 11: / Line 11: @@
 = New Token Landing Page =
-The new token landing page property (org.owasp.csrfguard.NewTokenLandingPage) defines where to send a user if the token is being generated for the first time. This request is generated using auto-posting forms and will only contain the CSRF prevention token parameter, if applicable. All query-string or form parameters sent with the original request will be discarded. If this property is not defined, CSRFGuard will instead auto-post the user to the originally requested URI. The following configuration snippet instructs OWASP CSRFGuard to redirect the user to /Owasp.CsrfGuard.Test/index.html when the user visits a protected resource without having a corresponding CSRF token present in the HttpSession object:
+The new token landing page property (org.owasp.csrfguard.NewTokenLandingPage) defines where to send a user if the token is being generated for the first time. This request is generated using auto-posting forms and will only contain the CSRF prevention token parameter, if applicable. All query-string or form parameters sent with the original request will be discarded. If this property is not defined, CSRFGuard will instead auto-post the user to the original context and servlet path. The following configuration snippet instructs OWASP CSRFGuard to redirect the user to /Owasp.CsrfGuard.Test/index.html when the user visits a protected resource without having a corresponding CSRF token present in the HttpSession object:
   org.owasp.csrfguard.NewTokenLandingPage=/Owasp.CsrfGuard.Test/index.html

@@ Line 11: / Line 11: @@
 = New Token Landing Page =
-The new token landing page property (org.owasp.csrfguard.NewTokenLandingPage) defines where to send a user if the token is being generated for the first time. CSRFGuard will redirect the user to the current page without any parameters if the property is not specified. Preventing the protected application from consuming a request whose session does not yet have a CSRF token through the use of a redirect prevents the execution of a one-time CSRF attack. The following configuration snippet instructs OWASP CSRFGuard to redirect the user to /Owasp.CsrfGuard.Test/index.html when they visit a protected resource without having a corresponding CSRF token present in the HttpSession object:
+The new token landing page property (org.owasp.csrfguard.NewTokenLandingPage) defines where to send a user if the token is being generated for the first time. This request is generated using auto-posting forms and will only contain the CSRF prevention token parameter, if applicable. All query-string or form parameters sent with the original request will be discarded. If this property is not defined, CSRFGuard will instead auto-post the user to the originally requested URI. The following configuration snippet instructs OWASP CSRFGuard to redirect the user to /Owasp.CsrfGuard.Test/index.html when the user visits a protected resource without having a corresponding CSRF token present in the HttpSession object:
   org.owasp.csrfguard.NewTokenLandingPage=/Owasp.CsrfGuard.Test/index.html

@@ Line 74: / Line 74: @@
 Allows the user to define the format of the log message to be recorded. The Message parameter supports several formatting options to aide in the customization of the message to the particular attack. The following formatting options are supported:
-  '''%exception''' - String representation of the CsrfGuardException thrown by the CsrfGuard class.
+  '''%exception%''' - String representation of the CsrfGuardException thrown by the CsrfGuard class.
-  '''%exception_message''' - Localized exception message of the class CsrfGuardException thrown by the CsrfGuard class.
+  '''%exception_message%''' - Localized exception message of the class CsrfGuardException thrown by the CsrfGuard class.
-  '''%remote_ip''' - Remote IP address of the client that sent the CSRF attack to the server.
+  '''%remote_ip%''' - Remote IP address of the client that sent the CSRF attack to the server.
-  '''%remote_host''' - Remote host name of the client that sent the CSRF attack to the server.
+  '''%remote_host%''' - Remote host name of the client that sent the CSRF attack to the server.
-  '''%remote_port''' - Remote port of the client that sent the CSRF attack to the server.
+  '''%remote_port%''' - Remote port of the client that sent the CSRF attack to the server.
-  '''%local_ip''' - Local IP address of the server that detected the CSRF attack.
+  '''%local_ip%''' - Local IP address of the server that detected the CSRF attack.
-  '''%local_host''' - Local host name of the server that detected the CSRF attack.
+  '''%local_host%''' - Local host name of the server that detected the CSRF attack.
-  '''%local_port''' - Local port of the server that detected the CSRF attack.
+  '''%local_port%''' - Local port of the server that detected the CSRF attack.
-  '''%request_uri''' - Request URI for which the CSRF attack was targeting.
+  '''%request_uri%''' - Request URI for which the CSRF attack was targeting.
-  '''%request_url''' - Request URL for which the CSRF attack was targeting.
+  '''%request_url%''' - Request URL for which the CSRF attack was targeting.
-  '''%user''' - User information as made available by the javax.servlet.http.HttpServletRequest.getRemoteUser() method invocation.
+  '''%user%''' - User information as made available by the javax.servlet.http.HttpServletRequest.getRemoteUser() method invocation.
 == org.owasp.csrfguard.action.Invalidate ==

← Older revision		Revision as of 22:51, 13 December 2010
Line 147:		Line 147:
	The pseudo-random number generator property (org.owasp.csrfguard.PRNG) defines what PRNG should be used to generate the OWASP CSRFGuard token. Always ensure this value references a cryptographically strong pseudo-random number generator algorithm. The following configuration snippet sets the pseudo-random number generator to SHA1PRNG:		The pseudo-random number generator property (org.owasp.csrfguard.PRNG) defines what PRNG should be used to generate the OWASP CSRFGuard token. Always ensure this value references a cryptographically strong pseudo-random number generator algorithm. The following configuration snippet sets the pseudo-random number generator to SHA1PRNG:
	org.owasp.csrfguard.PRNG=SHA1PRNG		org.owasp.csrfguard.PRNG=SHA1PRNG
		+
		+	[[Category:OWASP CSRFGuard Project]]

@@ Line 88: / Line 88: @@
 == org.owasp.csrfguard.action.Invalidate ==
-Invalidate any existing HttpSession associated with the current HttpServletRequest. Note that this is the session of the victim for which the CSRF attack was targeting. Invalidating the JavaEE container's session generally results in the user having to re-authenticate. There are no action parameters associated with this action.
+Invalidate any existing HttpSession associated with the current HttpServletRequest. Note that this is the session of the victim for which the CSRF attack was targeting. Invalidating the JavaEE container's session generally results in the user having to re-authenticate. There are no parameters associated with this action.
 == org.owasp.csrfguard.action.Redirect ==
@@ Line 121: / Line 121: @@
 Defines the attribute name that should be used when placing the CsrfGuardException in the HttpSession attributes collection.
 = Miscellaneous Configurations =

← Older revision		Revision as of 22:39, 13 December 2010
Line 31:		Line 31:

	org.owasp.csrfguard.Ajax=true		org.owasp.csrfguard.Ajax=true
−
−	~~= Referrer Checking =~~
−
−	The check referrer header property (org.owasp.csrfguard.Referrer) verifies that the supplied referrer header matches a regular expression. When enabled, verification of the referrer header will take precedence over verification of the CSRF token in the HTTP request. Referrer headers are consistently sent by browsers for pure HTTPS communications. Verification of the referrer header is a strong defense against CSRF attacks when consistently using HTTPS as a CSRF attack will not include this header in the request(s) unless the malicious HTML is embedded within the site for which the attack is targeted. Inclusion of the referrer header is less consistent when using traditional HTTP traffic across browsers. CSRFGuard will fall back to verifying the presence of the CSRF token if the referrer header was not included in the HTTP request. The following code snippet instructs OWASP CSRFGuard to verify that the referrer header matches the regular expression .localhost., ensuring the request came from a local resource:
−
−	org.owasp.csrfguard.Referrer=.localhost.

	= Unprotected Pages =		= Unprotected Pages =

@@ Line 28: / Line 28: @@
 = Ajax and XMLHttpRequest Support =
-The Ajax and XMLHttpRequest property (org.owasp.csrfguard.Ajax) indicates whether or not OWASP CSRFGuard should check for the presence of the X-Requested-With (case insensitive) header in the HTTP request. If the header is found, then we have strong evidence that the request was sent using the XMLHttpRequest object. As long as the browser properly enforces the Same Origin Policy with regards to the use of XMLHttpRequest, verification of the header is a strong defense against CSRF attacks for Ajax applications. Note that verification of the X-Requested-With header takes precedence over verification of the CSRF token supplied as an HTTP parameter. More specifically, CSRFGuard does not verify the presence of the CSRF token if the Ajax support property is enabled and the X-Requested-With header is embedded within the request. The following configuration snippet instructs OWASP CSRFGuard to support Ajax requests by verifying the presence of the X-Requested-With header:
+The Ajax property (org.owasp.csrfguard.Ajax) is a boolean value that indicates whether or not OWASP CSRFGuard should support the injection and verification of unique per-session prevention tokens for XMLHttpRequests. To leverage Ajax support, the user must not only set this property to true but must also reference the [[CSRFGuard_3_Token_Injection#JavaScript_DOM_Manipulation | JavaScript DOM Manipulation]] code using a script element. This dynamic script will override the send method of the XMLHttpRequest object to ensure the submission of an X-Requested-With header name value pair coupled with the submission of a custom header name value pair for each request. The name of the custom header is the value of the token name property and the value of the header is always the unique per-session token value. This custom header is analogous to the HTTP parameter name value pairs submitted via traditional GET and POST requests. If the X-Requested-With header was sent in the HTTP request, then CSRFGuard will look for the presence and ensure the validity of the unique per-session token in the custom header name value pair. Note that verification of these headers takes precedence over verification of the CSRF token supplied as an HTTP parameter. More specifically, CSRFGuard does not verify the presence of the CSRF token if the Ajax support property is enabled and the corresponding X-Requested-With and custom headers are embedded within the request. The following configuration snippet instructs OWASP CSRFGuard to support Ajax requests by verifying the presence and correctness of the X-Requested-With and custom headers:
   org.owasp.csrfguard.Ajax=true

← Older revision		Revision as of 22:21, 13 December 2010
Line 14:		Line 14:

	org.owasp.csrfguard.NewTokenLandingPage=/Owasp.CsrfGuard.Test/index.html		org.owasp.csrfguard.NewTokenLandingPage=/Owasp.CsrfGuard.Test/index.html
		+
		+	= Unique Token Per Page =
		+
		+	The unique token per-page property (org.owasp.csrfguard.TokenPerPage) is a boolean value that determines if CSRFGuard should make use of unique per-page (i.e. URI) prevention tokens as opposed to unique per-session prevention tokens. When a user requests a protected resource, CSRFGuard will determine if a page specific token has been previously generated. If a page specific token has not yet been previously generated, CSRFGuard will verify the request was submitted with the per-session token intact. After verifying the presence of the per-session token, CSRFGuard will create a page specific token that is required for all subsequent requests to the associated resource. The per-session CSRF token can only be used when requesting a resource for the first time. All subsequent requests must have the per-page token intact or the request will be treated as a CSRF attack. Use of the unique token per page property is currently experimental but provides a significant amount of improved security. Consider the exposure of a CSRF token using the legacy unique per-session model. Exposure of this token facilitates the attacker's ability to carry out a CSRF attack against the victim's active session for any resource exposed by the web application. Now consider the exposure of a CSRF token using the experimental unique token per-page model. Exposure of this token would only allow the attacker to carry out a CSRF attack against the victim's active session for a small subset of resources exposed by the web application. Use of the unique token per-page property is a strong defense in depth strategy significantly reducing the impact of exposed CSRF prevention tokens. The following configuration snippet instructs OWASP CSRFGuard to utilize the unique token per-page model:
		+
		+	org.owasp.csrfguard.TokenPerPage=true

	= Token Rotation =		= Token Rotation =

@@ Line 28: / Line 28: @@
 = Referrer Checking =
-The check referrer header property (org.owasp.csrfguard.Referrer) verifies that the supplied referrer header matches a regular expression. When enabled, verification of the referrer header will take precedence over verification of the CSRF token in the HTTP request. Referrer headers are consistently sent by browsers for pure HTTPS communications. Verification of the referrer header is a strong defense against CSRF attacks when consistently using HTTPS as a CSRF attack will not include this header in the request(s) unless the malicious HTML is embedded within the site for which the attack is targeted. Inclusion of the referrer header is less consistent when using traditional HTTP traffic across browsers. CSRFGuard will fall back to verifying the presence of the CSRF token if the referrer header was not included in the HTTP request. The following code snippet instructs OWASP CSRFGuard to verify that the referrer header matches the regular expression .*localhost.*, ensuring the request came from a local resource.
+The check referrer header property (org.owasp.csrfguard.Referrer) verifies that the supplied referrer header matches a regular expression. When enabled, verification of the referrer header will take precedence over verification of the CSRF token in the HTTP request. Referrer headers are consistently sent by browsers for pure HTTPS communications. Verification of the referrer header is a strong defense against CSRF attacks when consistently using HTTPS as a CSRF attack will not include this header in the request(s) unless the malicious HTML is embedded within the site for which the attack is targeted. Inclusion of the referrer header is less consistent when using traditional HTTP traffic across browsers. CSRFGuard will fall back to verifying the presence of the CSRF token if the referrer header was not included in the HTTP request. The following code snippet instructs OWASP CSRFGuard to verify that the referrer header matches the regular expression .*localhost.*, ensuring the request came from a local resource:
   org.owasp.csrfguard.Referrer=.*localhost.*