Horde form tokens

[Andrew Morgan]

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?

Right now, I have the Token System disabled ($conf[token][driver] =
"none").

So far as I know, this is the only person reporting this problem.  Any
advice on how I can track down what is happening here?

Thanks,
  Andy
--
Horde mailing list - Join the hunt: http://horde.org/bounties/#horde
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: horde-unsubscribe@...

[Chuck Hagenbuch]

Quoting Andrew Morgan <morgan@...>:

> 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.

-chuck
--
Horde mailing list - Join the hunt: http://horde.org/bounties/#horde
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: horde-unsubscribe@...

[Andrew Morgan]

On Mon, 6 Jul 2009, Chuck Hagenbuch wrote:

> Quoting Andrew Morgan <morgan@...>:
>
>> 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
--
Horde mailing list - Join the hunt: http://horde.org/bounties/#horde
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: horde-unsubscribe@...

[Chuck Hagenbuch]

Quoting Andrew Morgan <morgan@...>:

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

A token is generated for the action being taken (separate tokens for  
logout, compose, etc.). It is stored in the session, and also put into  
the form data for the action. When the action is submitted, the token  
has to be in the user's session and not expired.

The relevant code for your version is in imp/lib/IMP.php, in  
getRequestToken and checkRequestToken.

Looking there now, it looks like the FW3/IMP implementation uses  
seconds, not minutes, so you might check that. HOWEVER - the error  
message your user is getting indicates that the token isn't in their  
session at all, not that it has timed out. That's why I asked about  
external auth or potential session resets.

-chuck
--
Horde mailing list - Join the hunt: http://horde.org/bounties/#horde
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: horde-unsubscribe@...

[Andrew Morgan]

On Thu, 9 Jul 2009, Chuck Hagenbuch wrote:

> Quoting Andrew Morgan <morgan@...>:
>
>> How does the CSRF work?  Maybe if I understood what was happening I could
>> debug it further on my end.
>
> A token is generated for the action being taken (separate tokens for logout,
> compose, etc.). It is stored in the session, and also put into the form data
> for the action. When the action is submitted, the token has to be in the
> user's session and not expired.
>
> The relevant code for your version is in imp/lib/IMP.php, in getRequestToken
> and checkRequestToken.
>
> Looking there now, it looks like the FW3/IMP implementation uses seconds, not
> minutes, so you might check that. HOWEVER - the error message your user is
> getting indicates that the token isn't in their session at all, not that it
> has timed out. That's why I asked about external auth or potential session
> resets.

Okay, I'm checking with the user to see if they are logged out at the time
this error occurs.

Side note - it seems there are 2 token_lifetime config parameters:

$conf['urls']['token_lifetime'] = 240;  (in horde's conf.php)
$conf['server']['token_lifetime'] = 1800;  (in imp's conf.php)

The horde parameters is specified in minutes and the imp parameter is
specified in seconds.

Do these parameters both serve the same purpose?  Should I set them to the
same value (in the appropriate unit of time)?  I'm not sure why I
increased the horde value from the default 30 minutes to 240 minutes.  Are
other folks using higher values, or should I stick to the defaults?

Thanks,
  Andy

--
Horde mailing list - Join the hunt: http://horde.org/bounties/#horde
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: horde-unsubscribe@...

[Chuck Hagenbuch]

Quoting Andrew Morgan <morgan@...>:

> Okay, I'm checking with the user to see if they are logged out at  
> the time this error occurs.
>
> Side note - it seems there are 2 token_lifetime config parameters:
>
> $conf['urls']['token_lifetime'] = 240;  (in horde's conf.php)
> $conf['server']['token_lifetime'] = 1800;  (in imp's conf.php)

Yup. We added the feature after Horde 3.0, so for backwards  
compatibility it needed to be in both places.

> The horde parameters is specified in minutes and the imp parameter  
> is specified in seconds.

I think we changed the Horde one. We could change the IMP one too, but  
at this point the IMP one is deprecated in git.

> Do these parameters both serve the same purpose?  Should I set them  
> to the same value (in the appropriate unit of time)?  I'm not sure  
> why I increased the horde value from the default 30 minutes to 240  
> minutes.  Are other folks using higher values, or should I stick to  
> the defaults?

I would say you want the same effective value, yes.

-chuck
--
Horde mailing list - Join the hunt: http://horde.org/bounties/#horde
Frequently Asked Questions: http://horde.org/faq/
To unsubscribe, mail: horde-unsubscribe@...