Re-Authentication for expired Tokens - Revision history

Dirk: added a link to the Troubleshooting Authentication Problems page

2010-11-27T17:08:21Z

added a link to the Troubleshooting Authentication Problems page

Dirk: fixed version number note

2010-05-18T15:20:35Z

fixed version number note

Dirk: explicit call to SECINT_recreateFilesArray no longer necessary; clarified correct use of SEC_checkToken

2009-12-30T09:09:26Z

explicit call to SECINT_recreateFilesArray no longer necessary; clarified correct use of SEC_checkToken

Dirk: forgot to explain the use of SECINT_recreateFilesArray()

2009-12-29T14:52:13Z

forgot to explain the use of SECINT_recreateFilesArray()

Dirk: added a screenshot of the re-authentication form

2009-12-29T14:37:47Z

added a screenshot of the re-authentication form

Dirk: Known Issues

2009-12-29T13:37:00Z

Known Issues

Dirk: Re-Authentication for expired Tokens

2009-12-29T13:31:30Z

Re-Authentication for expired Tokens

New page

== Background ==

The introduction of [[CSRF Protection]] migitates the risk of Cross Site Request Forgery (CSRF) attacks on Geeklog sites. At the same time, however, it inconveniences Admin users, since an expired token will invalidate a request and may lead to data loss.

Re-authentication (currently only implemented in the 1.6.2hg development version) attempts to address this problem.

== How it works ==

Following the [[CSRF Protection#Considerations|recommendations]] for the use of security tokens, a call to <tt>SEC_checkToken()</tt> will check the token for validity. Previously, that function simply returned <tt>false</tt> when the token was not valid.

From now on, when <tt>SEC_checkToken()</tt> detects an invalid token, it will instead display a re-authentication form. This form explains what just happened and asks the user to enter their username and password. If the user provides the correct information, the previous request is recreated and sent again automatically. As a result, the last changes are ''not'' lost and the request is processed as if a valid token had been found.

=== Recreating Requests ===

The re-authentication form contains the information from the last request (GET or POST) in hidden fields, i.e. the entire <tt>$_GET</tt> and <tt>$_POST</tt> arrays, as well as the information from <tt>$_FILES</tt>, if files were uploaded with the failed request (the uploaded files themselves are temporarily stored in the site's 'data' directory).

On proper authentication, the GET or POST request is recreated from this information. A new security token is added and the request is sent to the original URL again. So from the target script's point of view, it looks like a regular request with a valid token came through.

In other words: The re-authentication and recreation of the request is entirely transparent. For scripts that already used CSRF protection, no code changes are required.

Well, there's one small exception ...

=== Uploaded Files ===

Files uploaded through the original request (the one with the expired token) are rescued and moved to the site's 'data' directory. This is necessary, as the files would automatically be deleted by PHP otherwise. As a result, the rescued files can no longer be moved with <tt>move_uploaded_file()</tt> since that function only works on files that were uploaded with the last POST request.

If you are using Geeklog's upload class (<tt>upload.class.php</tt>), this is handled automatically for you.

If you are using your own upload handling, then check the <tt>$_FILES</tt> array for an <tt>'_gl_data_dir'</tt> entry, e.g. <tt>$_FILES['file1']['_gl_data_dir']</tt>. If such an entry is present and not <tt>false</tt>, then use <tt>rename()</tt> instead of <tt>move_uploaded_file()</tt> to move the uploaded file to its destination. The <tt>'tmp_name'</tt> entry will already contain the correct path (for the 'data' directory), so you don't need to (and shouldn't) bother with its actual location.

[[Category:Development]]

@@ Line 75: / Line 75: @@
 * Re-authentication does not work for users that authenticate against OpenID (it does, however, work with other remote authentication modules like LDAP and LiveJournal).
 * When using a server running as localhost on Mac OS X, the recreated request may fail due to the current IP address being ::1 in the session but 127.0.0.1 in the recreated request.<br>'''Solution:''' Use the machine's Bonjour name (''xxx''.local) instead of localhost.
 [[Category:Development]]

@@ Line 3: / Line 3: @@
 The introduction of [[CSRF Protection]] migitates the risk of Cross Site Request Forgery (CSRF) attacks on Geeklog sites. At the same time, however, it inconveniences Admin users, since an expired token will invalidate a request and may lead to data loss.
-Re-authentication (currently only implemented in the 1.6.2hg development version) attempts to address this problem.
+Re-authentication (as of Geeklog 1.7.0) attempts to address this problem.
 [[Image:Reauthentication.png|center|Request for re-authentication]]

← Older revision		Revision as of 14:52, 29 December 2009
Line 24:		Line 24:

	=== Uploaded Files ===		=== Uploaded Files ===
		+
		+	First of all, if you expect files to be uploaded in your code, you need to call the new function <tt>SECINT_recreateFilesArray()</tt> somewhere ''after'' the call to <tt>SEC_checkToken()</tt> and ''before'' you access the <tt>$_FILES</tt> array for the first time. This function will ensure that a proper <tt>$_FILES</tt> array is recreated from the information provided in the recreated request.

	Files uploaded through the original request (the one with the expired token) are rescued and moved to the site's 'data' directory. This is necessary, as the files would automatically be deleted by PHP otherwise. As a result, the rescued files can no longer be moved with <tt>move_uploaded_file()</tt> since that function only works on files that were uploaded with the last POST request.		Files uploaded through the original request (the one with the expired token) are rescued and moved to the site's 'data' directory. This is necessary, as the files would automatically be deleted by PHP otherwise. As a result, the rescued files can no longer be moved with <tt>move_uploaded_file()</tt> since that function only works on files that were uploaded with the last POST request.

← Older revision		Revision as of 14:37, 29 December 2009
Line 5:		Line 5:
	Re-authentication (currently only implemented in the 1.6.2hg development version) attempts to address this problem.		Re-authentication (currently only implemented in the 1.6.2hg development version) attempts to address this problem.

		+	[[Image:Reauthentication.png\|center\|Request for re-authentication]]

	== How it works ==		== How it works ==

@@ Line 19: / Line 19: @@
 On proper authentication, the GET or POST request is recreated from this information. A new security token is added and the request is sent to the original URL again. So from the target script's point of view, it looks like a regular request with a valid token came through.
-In other words: The re-authentication and recreation of the request is entirely transparent. For scripts that already used CSRF protection, no code changes are required.
+In other words: '''The re-authentication and recreation of the request is entirely transparent. For scripts that already use CSRF protection, no code changes are required.'''
 === Uploaded Files ===
 Files uploaded through the original request (the one with the expired token) are rescued and moved to the site's 'data' directory. This is necessary, as the files would automatically be deleted by PHP otherwise. As a result, the rescued files can no longer be moved with <tt>move_uploaded_file()</tt> since that function only works on files that were uploaded with the last POST request.
@@ Line 32: / Line 28: @@
 If you are using your own upload handling, then check the <tt>$_FILES</tt> array for an <tt>'_gl_data_dir'</tt> entry, e.g. <tt>$_FILES['file1']['_gl_data_dir']</tt>. If such an entry is present and not <tt>false</tt>, then use <tt>rename()</tt> instead of <tt>move_uploaded_file()</tt> to move the uploaded file to its destination. The <tt>'tmp_name'</tt> entry will already contain the correct path (for the 'data' directory), so you don't need to (and shouldn't) bother with its actual location.