[horde] Horde form tokens

[Andrew Morgan]

On Mon, 6 Jul 2009, Chuck Hagenbuch wrote:

> Quoting Andrew Morgan <morgan at orst.edu>:
>
>> I am running the latest stable releases of Horde (3.3.4) and IMP (4.3.4). I 
>> have a user reporting the following:
>> 
>> -------------------------------------------------------
>> I've been getting this message a lot, lately, and now it appears when
>> I want to delete messages:
>> 
>> "We cannot verify that this request was really sent by you. It could
>> be a malicious request. If you intended to perform this action, you
>> can retry it now."
>> 
>> 1) I log in through the web by use of Safari on my own laptop, using
>> the wireless available at the house where I'm staying in Australia.
>> The network name is akck21jk09, but I haven't tracked it down yet.
>> 2) I delete any unwanted messages.
>> 3) I click on purge deleted.
>> 4) Then the message sometimes (not always) appears, "We cannot verify...."
>> 5. Then I try purging again, as the message indicates. Usually it will
>> let me purge, but sometimes it won't unless I close Safire, reopen,
>> and log in again.
>> 
>> The irritating message sometimes appears when I try to send a new
>> message or even when I reply to a message that did not produce any
>> warning. In that case, after I write my reply, I click send, and
>> sometimes (not always) the message appears. I reclick on send, and
>> usually (not always), it permits the message to be sent.
>> -------------------------------------------------------
>> 
>> Is this triggered by the CSRF form token protection?
>
> It is triggered by the CSRF protection. This is different from (though 
> similar to) the form token system.
>
>> Right now, I have the Token System disabled ($conf[token][driver] = 
>> "none").
>
> That isn't relevant to these tokens.
>
>> Any advice on how I can track down what is happening here?
>
> Are you using a custom auth driver that might reset the user's $_SESSION 
> variable? That could do this. Otherwise you might check 
> $conf['urls']['token_lifetime'], which controls how long request tokens are 
> valid for.

I have auth handled by IMP.

$conf['urls']['token_lifetime'] = 240;
$conf['urls']['hmac_lifetime'] = 120;

I doubt the user is running into the 240 minute limit as often as he 
describes the problem happening.  :)

How does the CSRF work?  Maybe if I understood what was happening I could 
debug it further on my end.

Thanks,
 	Andy