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

[Michael M Slusarz]

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.

And I am *very* concerned about users seeing anything about "this  
action may not have been performed by you".  That is a scary error  
message, and I can't think of another application I've ever been on  
that I've ever had to deal with that.

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

I meant an attacker isn't going to bother to try to hack *Horde* as a  
whole, or is less likely to target, since a much easier attack is  
available against other sites that don't do token protection.

Obviously, this is pointless if a specific attacker wants to attack a  
specific Horde installation for whatever reason (i.e. targeting a  
particular user), but it does prevent more general Spammer-like  
behavior.  That's just basic economic theory - people aren't going to  
waste their time on something unless they are getting something out of  
it.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]