Adding Random Tokens for Form Submissions

[Ian Andolina (copied by NilsLindenberg)]

Based on  this post, I wonder whether providing randomised session tokens for form submission may provide just one more step to impede spambots. Very simple to implement:

wikka.php:

function FormOpen($method = "", $tag = "", $formMethod = "post")
{
	if(!isset($_SESSION['token'])) {
		$token = md5(uniqid(rand(), true));
		$_SESSION['token'] = $token;
	}
	$result = "<form action=\"".$this->Href($method, $tag)."\" method=\"".$formMethod."\"><p>\n";
	$result .= "<input type=\"hidden\" name=\"token\" value=\"".$_SESSION['token']."\" />";
	if (!$this->config["rewrite_mode"]) $result .= "<input type=\"hidden\" name=\"wakka\" value=\"".$this->MiniHref($method, $tag)."\" />\n";
	return $result;
}

and then just wrap edit.php and addcomment.php sections using:

if ($_POST['token'] == $_SESSION['token']) { //form spoof protection

}

I'm definitely no expert on security, and I can see how it can be bypassed, but it does require one more step and adds complexity for spambots to spoof the wiki forms at no cost... --IanAndolina

Good point, Ian. I had been thinking about a similar approach (I have a plugin for SquirrelMail installed that essentially does the same thing for the login dialog) - but reading therough the comments on  Chris Shiflett's article it's clear that this is no more than another little hurdle easily overcome by the script-writing link spammer (GET the page with the script first, read the token and use that in the scripted POST). That said, it is another hurdle that may deter at least some naive spammers - and with very little code. So, nice. --JavaWoman (who suddenly realizes her Squirrelmail isn't as secure as she thought it was - but at least has built in other layers of security)

Related Tickets

#855 Adding Random Tokens for Edit Form Submissions
#889 Form IDs need to be regenerated after each form submission

[NilsLindenberg]

Installed as a beta code on wikkawiki.org, so we can take the code from there.

[DarTar]

changing milestone for consideration for 1.1.6.4 as an antispam feature

[JavaWoman]

Basically this is what is already implemented as "secret session key" as experimental feature on our site - except it's implemented differently and more refined already ;) (field/token name is also random, for instance, and a provision to make the "token" unique per page) - and in line for 1.1.6.4 anyway (awaiting agreement on antispam plugin architecture).

It still needs work though, to make the token unique to a particular form as well (not just a page) since there can be multiple forms on a page; each session may need to store several different tokens, because a visitor may have different pages open, each with multiple forms, and even the same page open multiple times (our original implementation frequently caused comments to be rejected...). Welcome to the age of tabbed browsing. ;)

[DarTar]

Marjolein, any update on this? It'd be great to make this part of the AS features of 1.1.6.4 if the basic functionality is already coded. We'll be able to finetune the code in 1.1.7 anyway.

[DarTar]

(bumping)

[BrianKoontz]

Deferred to 1.1.7.

[DarTar]

(In [1277]) [antispam] preliminary implementation of secret session keys (credits: JavaWoman), refs #154

[DarTar]

Applied to comment forms, please test.

[BrianKoontz]

I received an error message when I copied the page, modified the token, and tried to POST the page back to the server. Looks like this is working as advertised!

[BrianKoontz]

Accidentally removed from testing state. Looks like there's more work to be done on this one, so I'll leave it as commit pending further changes.

[DarTar]

Brian, I'm not sure there's anything left here, what were you thinking of?

[BrianKoontz]

I was thinking of edit forms...but as we discussed on IRC, we'll defer this until 1.7.

[BrianKoontz]

(In [1341]) Ported to trunk. Refs #154.

[NilsLindenberg]

Now implemented for all $_POST forms:

[1351] #154 part 1: moving session handling from antispam lib to core.

[1352] #154 part 2: adding check to appropriate handlers

[1353] #154 part 3: adding check to appropriate action

[1354] part 4: deletion of now unnecessary lib

[1355] - [1357] fixing of char issues and turning off debug messages

Basically it now works as proposed: every FormOpen(post) gets two hidden fields: the form id and a form token. Handlers (addcomment, deletecomment, edit [on page-save], delete) and the usersettings action counter-check and discard the data posted to them if the test isn't passed.

Todo: clone handler, files handler, edit handler(preview)

[NilsLindenberg]

(In [1359]) refs #154: adding check to acls handler

[BrianKoontz]

(In [1362]) Undoing changes committed in #154, [1351]-[1359]. These will be re-committed in the 1.1.6.7 branch. Refs #154, #784, #877.

[BrianKoontz]

(In [1363]) Updated WAKKA_VERSION to 1.1.6.7. There is no need to re-commit [1351]-[1359] as these changes were already included with the branch copy from 1.1.6.6 to 1.1.6.7. Refs #154, #784, #877.

[BrianKoontz]

(In [1364]) Cleanup; made error messages consistent across handlers. Refs #154.

[BrianKoontz]

Issues carried over from the dev mailing list:

On Fri, May 01, 2009 at 11:08:21PM -0500, Brian Koontz wrote:              
> I'm at a loss how to test the delete handler for proper form_id          
> functionality (re #154).   I seem to always be able to delete pages,     
> even after coying pages and reopening them in another browser.           
                                                                           
I'm not having much luck with testing the edit handler either.  Here       
are my steps:                                                              
                                                                           
1) Save a copy of a page as an HTML file.                                  
2) Log off.                                                                
3) Log back on.                                                            
4) Open copy of page.                                                      
5) Click edit link in copy.                                                
6) Edit window opens.                                                      
                                                                           
It seems to me that once you log off, and log back on, a new session       
key should be created.  Old session keys should be discarded at this       
point.  No saved forms should permit handlers to be called (such as by     
the edit link).                                                            
                                                                           
Also, once a form is posted, shouldn't that form_id be deleted from        
the $_SESSION var?  Otherwise, the form_id keys remain, allowing forms     
that have been saved to be called again and again.    

[DarTar]

Replying to BrianKoontz:

It seems to me that once you log off, and log back on, a new session key should be created. Old session keys should be discarded at this point. No saved forms should permit handlers to be called (such as by the edit link).

Brian, indeed the edit window opens following your steps - I fail to se why this represents a security issue though as the link simply calls a currently open session (am I missing something here?). OTOH I agree we could remove form_id after a form is (successfully) posted.

[BrianKoontz]

I'll open a low-priority ticket to resolve this one issue about the form ID, and close this one out as resolved.

[BrianKoontz]

In ([1358]): #154: turn of debug messages :)

[BrianKoontz]

(In [1382]) Ported from 1.1.6.7 to 1.2. Refs #154, #868.