CSRFGuard 2.2 ChangeLog - Revision history

Esheridan at 00:42, 10 April 2008

2008-04-10T00:42:08Z

Esheridan at 00:38, 10 April 2008

2008-04-10T00:38:09Z

Esheridan at 00:35, 10 April 2008

2008-04-10T00:35:07Z

Esheridan at 00:33, 10 April 2008

2008-04-10T00:33:09Z

Esheridan at 22:47, 9 April 2008

2008-04-09T22:47:48Z

Esheridan at 22:46, 9 April 2008

2008-04-09T22:46:08Z

Esheridan at 22:34, 9 April 2008

2008-04-09T22:34:01Z

Esheridan at 21:26, 9 April 2008

2008-04-09T21:26:06Z

Esheridan: /* Detailed Change List */

2008-04-05T20:51:23Z

‎Detailed Change List

Esheridan at 18:21, 5 April 2008

2008-04-05T18:21:53Z

@@ Line 32: / Line 32: @@
   '''Developer Can Specify Initial Landing Page Upon Token Creation'''
-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.
+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.
   '''Fixed a Number of Code Quality Bugs'''

@@ Line 28: / Line 28: @@
   '''Optionally Verify Token If Parameters Exist 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.
+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.
   '''Developer Can Specify Initial Landing Page Upon Token Creation'''

@@ Line 28: / Line 28: @@
   '''Optionally Verify Token If Parameters Exist 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.
+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.
   '''Developer Can Specify Initial Landing Page Upon Token Creation'''

@@ Line 28: / Line 28: @@
   '''Optionally Verify Token If Parameters Exist 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.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.
+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.
   '''Developer Can Specify Initial Landing Page Upon Token Creation'''

@@ Line 28: / Line 28: @@
   '''Optionally Verify Token If Parameters Exist 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.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.
+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.
   '''Developer Can Specify Initial Landing Page Upon Token Creation'''

@@ Line 36: / Line 36: @@
   '''Fixed a Number of Code Quality Bugs'''
-The OWASP CSRFGuard 2.0 release was a bit rushed as I was trying to get all of the latest features implemented in time for the OWASP San Jose conference last year. As a result, a number of code quality bugs slipped by me. One such issue was an endless loop in the FilterOutputStream object. To address this issue, three major changes were implemented for this release - the appropriate use of a unit testing framework (jUnit), the use of code quality static analyzer(s) (FindBugs), and a more stringent peer review. OWASP CSRFGuard 2.0 users are strongly encouraged to update to the latest release.
+The OWASP CSRFGuard 2.0 release was a bit rushed as I was trying to get all of the latest features implemented in time for the OWASP San Jose conference last year. As a result, a number of code quality bugs slipped by me. One such issue was an endless loop in the FilterOutputStream object. To address this issue, three major changes were implemented for this release - the appropriate use of a unit testing framework (jUnit), the use of code quality static analyzer(s) (FindBugs, PMD), and a more stringent peer review. OWASP CSRFGuard 2.0 users are strongly encouraged to update to the latest release.
   '''The RegExHandler is Deprecated'''
 Sorry guys - that class was a complete hack since day one of CSRFGuard. That "buildLinkParameters" method is quite possibly the ugliest code I've written since working on a particular VBA application. There are so many better and more useful options that I've decided not to spend my limited energy improving this response handler. If someone would like to lead the development of the RegExHandler, shoot me an email.

← Older revision		Revision as of 20:51, 5 April 2008
Line 12:		Line 12:


−	While I would love to take credit for this idea, in good conscience I cannot. A buddy of mine at the OWASP San Jose conference suggested the idea after [http://www.owasp.org/images/c/c9/CSRF_DangerDetectionDefenses.ppt I gave my talk about CSRFTester and CSRFGuard]. I must say - it is an honor to be around so many smart people in this community!	+	While I would love to take credit for this idea, although in good conscience I cannot. A buddy of mine at the OWASP San Jose conference suggested the idea after [http://www.owasp.org/images/c/c9/CSRF_DangerDetectionDefenses.ppt I gave my talk about CSRFTester and CSRFGuard]. I must say - it is an honor to be around so many smart people in this community!

	'''JavaScript Handler Processes All DOM Elements'''		'''JavaScript Handler Processes All DOM Elements'''

← Older revision		Revision as of 18:21, 5 April 2008
Line 37:		Line 37:

	The OWASP CSRFGuard 2.0 release was a bit rushed as I was trying to get all of the latest features implemented in time for the OWASP San Jose conference last year. As a result, a number of code quality bugs slipped by me. One such issue was an endless loop in the FilterOutputStream object. To address this issue, three major changes were implemented for this release - the appropriate use of a unit testing framework (jUnit), the use of code quality static analyzer(s) (FindBugs), and a more stringent peer review. OWASP CSRFGuard 2.0 users are strongly encouraged to update to the latest release.		The OWASP CSRFGuard 2.0 release was a bit rushed as I was trying to get all of the latest features implemented in time for the OWASP San Jose conference last year. As a result, a number of code quality bugs slipped by me. One such issue was an endless loop in the FilterOutputStream object. To address this issue, three major changes were implemented for this release - the appropriate use of a unit testing framework (jUnit), the use of code quality static analyzer(s) (FindBugs), and a more stringent peer review. OWASP CSRFGuard 2.0 users are strongly encouraged to update to the latest release.
		+
		+	'''The RegExHandler is Deprecated'''
		+
		+	Sorry guys - that class was a complete hack since day one of CSRFGuard. That "buildLinkParameters" method is quite possibly the ugliest code I've written since working on a particular VBA application. There are so many better and more useful options that I've decided not to spend my limited energy improving this response handler. If someone would like to lead the development of the RegExHandler, shoot me an email.