CSRFGuard 2.2 Configuration Manual - Revision history

Michael Kopinsky at 06:09, 28 September 2010

2010-09-28T06:09:11Z

Esheridan: /* New Token Redirect Page */

2008-04-10T00:41:38Z

‎New Token Redirect Page

Esheridan: /* Parameterless Token Validation */

2008-04-10T00:38:40Z

‎Parameterless Token Validation

Esheridan: /* Parameterless Token Validation */

2008-04-10T00:34:47Z

‎Parameterless Token Validation

Esheridan at 00:33, 10 April 2008

2008-04-10T00:33:51Z

Esheridan: /* Parameterless Token Validation */

2008-04-09T22:48:25Z

‎Parameterless Token Validation

Esheridan: /* Parameterless Token Validation */

2008-04-09T22:45:23Z

‎Parameterless Token Validation

Esheridan: /* Parameterless Token Validation */

2008-04-09T22:42:45Z

‎Parameterless Token Validation

Esheridan at 22:40, 9 April 2008

2008-04-09T22:40:16Z

Esheridan at 22:27, 9 April 2008

2008-04-09T22:27:07Z

@@ Line 65: / Line 65: @@
   '''org.owasp.csrfguard.handlers.DefaultHandler'''
-The DefaultHandler is the "null terminator" of handlers. It does absolutely nothing. If you plan on using the CSRFGuard tag library, then you should specify the "DefaultHandler" as your response handler. For more information regarding the use of the tag library, [FIXME click here].
+The DefaultHandler is the "null terminator" of handlers. It does absolutely nothing. If you plan on using the CSRFGuard tag library, then you should specify the "DefaultHandler" as your response handler. For more information regarding the use of the tag library, see [[CSRFGuard_2.2_Tag_Usage]].
 The following sample configures CSRFGuard to use the DefaultHandler.

@@ Line 104: / Line 104: @@
 == New Token Redirect Page ==
-Previous releases of OWASP CSRFGuard had a very innocuous bug that allowed for a one-time CSRF attack against a particular session. In previous versions, when the first request came in for a session, the token was created and the request (valid or forged!) would be allow through. As a result, there existed the possibility of performing a CSRF attack against an unauthenticated and session-less user. To counter this particular deficiency, developers can specify a "landing page" for the initial request when the CSRF token is being created. Rather than allowing the initial request through after token creation, the user can be optionally redirected to a safe landing page. This is done by defining the "org.owasp.csrfguard.NewTokenRedirectPage" directive. The following example redirects the user to /TestApp/index.jsp when a new token is generated and placed in a new session:
+Previous releases of OWASP CSRFGuard had a very innocuous bug that allowed for a one-time CSRF attack against a particular session. In previous versions, when the first request came in for a session, the token was created and the request (valid or forged!) would be allowed through. As a result, there existed the possibility of performing a CSRF attack against an unauthenticated and session-less user. To counter this particular deficiency, developers can specify a "landing page" for the initial request when the CSRF token is being created. Rather than allowing the initial request through after token creation, the user can be optionally redirected to a safe landing page. This is done by defining the "org.owasp.csrfguard.NewTokenRedirectPage" directive. The following example redirects the user to /TestApp/index.jsp when a new token is generated and placed in a new session:
   # New Token Redirect Page

@@ Line 115: / Line 115: @@
 == Parameterless Token Validation ==
-Previous versions of CSRFGuard would validate every single request sent to a protected resource. Consider the case when you click the "Refresh" button or when you click a book mark. When these actions occur, no valid token will exist in the GET request. As a result, CSRFGuard will incorrectly detect an attack. To counter this issue, developers can configure OWASP CSRFGuard to only validate the request if there are one or more parameters in the request. This is achieved through the use of the "org.owasp.csrfguard.ParameterlessValidation" directive. If set to false, CSRFGuard will only validate if there is one or more parameters. If set to true, CSRFGuard will mark a parameterless request as a possible attack. Please understand the potential consequences of this configuration. There are many web applications (Ex. Drupal, http://www.drupal.org) that invoke server-side actions using parameterless requests. If your application has this behavior, then I would highly recommend you consider validating all requests by setting "ParameterlessValidation" to true. If your web application(s) does not invoke server-side actions using parameterless requests, consider setting "ParameterlessValidation" to false to increase overall user experience. The following configuration tells CSRFGuard to only validate the token if there exists one or more parameters in the request:
+Previous versions of CSRFGuard would validate every single request sent to a protected resource. Consider the case when you click the "Refresh" button or when you click a book mark. When these actions occur, no valid token will exist in the GET request. As a result, CSRFGuard will incorrectly detect an attack. To counter this issue, developers can configure OWASP CSRFGuard to only validate the request if there are one or more parameters in the request. This is achieved through the use of the "org.owasp.csrfguard.ParameterlessValidation" directive. If set to false, CSRFGuard will only validate if there is one or more parameters. If set to true, CSRFGuard will mark a parameterless request for a protected resource as a possible attack. Please understand the potential consequences of this configuration. There are many web applications (Ex. Drupal, http://www.drupal.org) that invoke server-side actions using parameterless requests. If your application has this behavior, then I would highly recommend you consider validating all requests by setting "ParameterlessValidation" to true. If your web application(s) does not invoke server-side actions using parameterless requests, consider setting "ParameterlessValidation" to false to increase overall user experience. The following configuration tells CSRFGuard to only validate the token if there exists one or more parameters in the request:
   # Parameterless Token Validation

@@ Line 115: / Line 115: @@
 == Parameterless Token Validation ==
-Previous versions of CSRFGuard would validate every single request sent to a protected resource. Consider the case when you click the "Refresh" button or when you click a book mark. When these actions occur, no valid token will exist in the GET request. As a result, CSRFGuard will incorrectly detect an attack. To counter this issue, developers can configure OWASP CSRFGuard to only validate the request if there are one or more parameters in the request. This is achieved through the use of the "org.owasp.csrfguard.ParameterlessValidation" directive. If set to false, CSRFGuard will only validate if there is one or more parameters. If set to true, CSRFGuard will mark a parameterless request as a possible attack. Please understand the potential consequences of this configuration. There are many web applications (Ex. Drupal, http://www.drupal.org) that invoke server-side actions using parameterless requests. If your application has this behavior, then I would highly recommend you consider validating all requests by setting "NoParameterValidate" to true. If your web application(s) does not invoke server-side actions using parameterless requests, consider setting "ParameterlessValidation" to false to increase overall user experience. The following configuration tells CSRFGuard to only validate the token if there exists one or more parameters in the request:
+Previous versions of CSRFGuard would validate every single request sent to a protected resource. Consider the case when you click the "Refresh" button or when you click a book mark. When these actions occur, no valid token will exist in the GET request. As a result, CSRFGuard will incorrectly detect an attack. To counter this issue, developers can configure OWASP CSRFGuard to only validate the request if there are one or more parameters in the request. This is achieved through the use of the "org.owasp.csrfguard.ParameterlessValidation" directive. If set to false, CSRFGuard will only validate if there is one or more parameters. If set to true, CSRFGuard will mark a parameterless request as a possible attack. Please understand the potential consequences of this configuration. There are many web applications (Ex. Drupal, http://www.drupal.org) that invoke server-side actions using parameterless requests. If your application has this behavior, then I would highly recommend you consider validating all requests by setting "ParameterlessValidation" to true. If your web application(s) does not invoke server-side actions using parameterless requests, consider setting "ParameterlessValidation" to false to increase overall user experience. The following configuration tells CSRFGuard to only validate the token if there exists one or more parameters in the request:
   # Parameterless Token Validation

@@ Line 115: / Line 115: @@
 == Parameterless Token Validation ==
-Previous versions of CSRFGuard would validate every single request sent to a protected resource. Consider the case when you click the "Refresh" button or when you click a book mark. When these actions occur, no valid token will exist in the GET request. As a result, CSRFGuard will incorrectly detect an attack. To counter this issue, developers can configure OWASP CSRFGuard to only validate the request if there are one or more parameters in the request. This is achieved through the use of the "org.owasp.csrfguard.NoParameterValidate" directive. If set to false, CSRFGuard will only validate if there is one or more parameters. If set to true, CSRFGuard will mark a parameterless request as a possible attack. Please understand the potential consequences of this configuration. There are many web applications (Ex. Drupal, http://www.drupal.org) that invoke server-side actions using parameterless requests. If your application has this behavior, then I would highly recommend you consider validating all requests by setting "NoParameterValidate" to true. If your web application(s) does not invoke server-side actions using parameterless requests, consider setting "NoParameterValidate" to false to increase overall user experience. The following configuration tells CSRFGuard to only validate the token if there exists one or more parameters in the request:
+Previous versions of CSRFGuard would validate every single request sent to a protected resource. Consider the case when you click the "Refresh" button or when you click a book mark. When these actions occur, no valid token will exist in the GET request. As a result, CSRFGuard will incorrectly detect an attack. To counter this issue, developers can configure OWASP CSRFGuard to only validate the request if there are one or more parameters in the request. This is achieved through the use of the "org.owasp.csrfguard.ParameterlessValidation" directive. If set to false, CSRFGuard will only validate if there is one or more parameters. If set to true, CSRFGuard will mark a parameterless request as a possible attack. Please understand the potential consequences of this configuration. There are many web applications (Ex. Drupal, http://www.drupal.org) that invoke server-side actions using parameterless requests. If your application has this behavior, then I would highly recommend you consider validating all requests by setting "NoParameterValidate" to true. If your web application(s) does not invoke server-side actions using parameterless requests, consider setting "ParameterlessValidation" to false to increase overall user experience. The following configuration tells CSRFGuard to only validate the token if there exists one or more parameters in the request:
   # Parameterless Token Validation
@@ Line 127: / Line 127: @@
   # Ex: /TestApp/index.jsp has no parameters. No need to validate. Clicking refresh will cause issues.
   # Ex: /AddCart/32 has no parameters. Visiting the URL will add item '32' to cart. We must validate token
-  org.owasp.csrfguard.NoParameterValidate=false
+  org.owasp.csrfguard.ParameterlessValidation=false

← Older revision		Revision as of 22:40, 9 April 2008
Line 101:		Line 101:
	# Define what PRNG should be used to generate the token		# Define what PRNG should be used to generate the token
	org.owasp.csrfguard.PRNG=SHA1PRNG		org.owasp.csrfguard.PRNG=SHA1PRNG
		+
		+	== New Token Redirect Page ==
		+
		+	Previous releases of OWASP CSRFGuard had a very innocuous bug that allowed for a one-time CSRF attack against a particular session. In previous versions, when the first request came in for a session, the token was created and the request (valid or forged!) would be allow through. As a result, there existed the possibility of performing a CSRF attack against an unauthenticated and session-less user. To counter this particular deficiency, developers can specify a "landing page" for the initial request when the CSRF token is being created. Rather than allowing the initial request through after token creation, the user can be optionally redirected to a safe landing page. This is done by defining the "org.owasp.csrfguard.NewTokenRedirectPage" directive. The following example redirects the user to /TestApp/index.jsp when a new token is generated and placed in a new session:
		+
		+	# New Token Redirect Page
		+	#
		+	# Defines where to send a user if the token is being generated for the first time.
		+	# Failure to define a redirect page will allow CSRF attacks to work for unauthenticated
		+	# users
		+	org.owasp.csrfguard.NewTokenRedirectPage=/TestApp/index.jsp
		+
		+	== Parameterless Token Validation ==
		+
		+	Previous versions of CSRFGuard would validate every single request sent to a protected resource. Consider the case when you click the "Refresh" button or when you click a book mark. When these actions occur, no valid token will exist in the GET request. As a result, CSRFGuard will incorrectly detect an attack. To counter this issue, developers can configure OWASP CSRFGuard to only validate the request if there are one or more parameters in the request. If enabled, parameterless requests will not be validated by OWASP CSRFGuard. Please understand the potential consequences of this configuration. There are many web applications (Ex. Drupal, http://www.drupal.org) that invoke server-side actions using parameterless requests. If your application has this behavior, then I would highly recommend you consider disabling this feature. The following configuration tells CSRFGuard to only validate the token if there exists one or more parameters in the request:
		+
		+	# Parameterless Token Validation
		+	#
		+	# Define whether or not the token validation should occur
		+	# on pages that do not have HTTP parameters (except for the token itself).
		+	#
		+	# If false, only validate when there is at least one parameter
		+	# If true, validate regardless of the number of parameters
		+	#
		+	# Ex: /TestApp/index.jsp has no parameters. No need to validate. Clicking refresh will cause issues.
		+	# Ex: /AddCart/32 has no parameters. Visiting the URL will add item '32' to cart. We must validate token
		+	org.owasp.csrfguard.NoParameterValidate=false

@@ Line 3: / Line 3: @@
 == Overview ==
-OWASP CSRFGuard 2.2 offers several advantages over previous releases. With these advantages comes a number of new and or updated configuration options. The purpose of this article is to document all of the configuration options supported by CSRFGuard 2.2 as well as any relevant use cases.
+OWASP CSRFGuard 2.2 offers several advantages over previous releases. With these advantages comes a number of new and or updated configuration options. The purpose of this article is to document all of the configuration options supported by CSRFGuard 2.2 as well as any relevant use cases. All of this properties are configured in the "CSRFGuard.properties" file included in the "/conf" folder of the 2.2 distribution.
 == Response Handler ==
@@ Line 73: / Line 73: @@
 '''Note:''' It is vitally important to thoroughly test the ResponseHandler in your environment before deploying it to production. There is risk that the modification of your HTML might break existing functionality.