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

[Michael M Slusarz]

Quoting Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>> 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.
>
> I don't understand how changing the token in the case of XSS  
> provides any additional security.  The XSS can easily determine  
> whether the token changed or not.  This is trivial.  How does  
> switching fix this?
>
> Once you have an XSS vulnerability, token checking becomes moot.

So I've done a bit of research on the subject, and expiring tokens is  
worthless.  It provides no appreciable additional security protection,  
at the expense of severely affecting the UI.

 From the OWASP white-page on CSRF:

"In general, developers need only generate this token once for the  
current session. After initial generation of this token, the value is  
stored in the session and is utilized for each subsequent request  
until the session expires."

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet

Tokens are worthless as a security measure when it comes to XSS  
attacks, so that is no justification.

The only place token regeneration at an interval would be useful is if  
the token somehow "leaked" to a foreign page - e.g. in a URL.  But 1)  
that shouldn't happen with our code and 2) it still only provides  
minimal protection; after all, the attacker can still attack if it  
does happen.  For destructive actions, it's kind of pointless if the  
attacker can no longer perform the task 30 minutes later since they've  
already accomplished what they wanted in the first request.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]