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

The economic argument is of course correct, but gaining access to  
(any) webmail account is so valuable to spammers that they would try  
to jump through many loops before giving up. Some other random  
unprotected service is not nearly as much worth it being hacked. But  
anyway, the more protection we provide, the less economic it becomes  
for an attacker to target Horde.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/