[dev] Token lifetimes (was Re: [imp] EMERG: HORDE Diese Anfrage konnte nicht durchgeführt werden)

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Samuel Wolf <samuel at sheepflock.de>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>> Quoting samuel at sheepflock.de:
>>>
>>>> Hi,
>>>>
>>>> I update yesterday to the current horde release (horde 5.1.5, imp 
>>>> 6.1.5,..) and see this error today when I print a mail:
>>>> 2013-10-30T15:16:49+00:00 EMERG: HORDE [imp] Diese Anfrage konnte 
>>>> nicht durchgeführt werden, weil der Link oder das Formular, das Sie 
>>>> abgeschickt haben, nur 30 Minuten gültig war. Bitte versuchen Sie es 
>>>> jetzt noch einmal. [pid 18110 on line 167 of 
>>>> "/usr/share/php/Horde/Token/Base.php"]
>>>>
>>>> Switch Horde app, mailfolder or message (sorry can not remember) and 
>>>> it work again.
>>>> Somebody a idea what went wrong?
>>>> Some timeout, because it work over hours before...
>>>
>>> Increase your token timeout.
>>
>> This one?
>> conf.php:$conf['urls']['token_lifetime'] = 30;
>
> Yes.
>
> I'm wondering if we shouldn't get rid of this entirely and simply  
> revert to per session tokens.  At least for authenticated people.   
> (And even for guest users, we are assuming that have a session when  
> accessing application resources, right?  )
>
> For example: It's not that uncommon to open a message, get  
> distracted, and then try to open a token-protected URL more than 30  
> minutes later.
>
> Session tokens are designed to prevent *static* CSRF attacks.   
> Having a session-length token prevents these attacks.
>
> Changing tokens within the session is meant to prevent *dynamic*  
> attacks.  I don't think we gain much since if an attacker has to  
> somehow gain access to your session information and grab the token  
> to perform the attack 1) they are probably going to launch a more  
> direct attack anyway (since, to get this information, they have  
> likely gained access through a different security hole),

What do you consider a more direct attack? Such an attack vector is  
not necessarily available, just because you have been able to trigger  
a CSRF. Those are usually possible by exploiting some unfixed XSS  
vulnerability, that's why XSS and CSRF often go hand-in-hand.
And this is the most common scenario that changing tokens could  
protect against.

> and 2) it won't even reach this point, since an attacker will switch  
> to another service that doesn't token protect in the first place.

Moot point because we try to token-protect *all* important or  
destructive actions, services that are not protected are most probably  
not interesting to the attacker.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/