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

Thanks for looking this up. Makes sense.

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

True.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/