[dev] [commits] Horde branch develop updated. f371e6d4658e43d440c4e7dcd923f7db5faed574

[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>:
>>
>>> f371e6d [mms] Token protect AJAX logout link.
>>
>> But those tokens timeout, no? That's at least the reason why we  
>> used the on-demand redirect.
>
> Maybe I am confusing with something else... but I thought the recent  
> changes with the Token library allowed Tokens with an indefinite  
> lifetime.
>
> ...and now that I looked at the code, the verification action in  
> login.php *is* ignoring the configured token lifetime.  But these  
> logout tokens may still be purged by a call to verify() from some  
> other page in the meantime.  So a valid logout link is not 100%  
> guaranteed to be available currently.  This is unacceptable, IMHO.
>
> I guess I am a bit confused by the need for the Token library in the  
> first place, at least for token-protected links in a valid session.   
> It seems to make much more sense to define a single token in the  
> session on login, and use this token for all necessary  
> token-protected URLs.  As a proof of concept, I have converted ALL  
> AJAX actions to be token protected using this strategy.  The session  
> token can be obtained via Horde_Session#getToken() and checked via  
> Horde_Session#checkToken().
>
> Revisting Horde_Token: do we really need tokens that timeout?  Using  
> session storage, we would get tokens that will automatically timeout  
> with the session.  I believe the theory behind token lifetimes is  
> that an attacker would be able to hijack a session, determine the  
> token, use this token to craft an invalid URL, and then somehow  
> transport this URL to a user (e.g. mail message).  But is this  
> really a viable attack?  Specifically, if an attacker is able to  
> grab the token, they can grab the session ID at the same time - and  
> this would be a much more desirable target.

It IS a viable attack, it's the gist of CSRF. And the protection of  
URLs with tokens only make sense if those are one-time, expiring  
tokens. What you describe is exactly the attack vector. The attacker  
usually uses an unpatched XSS vulnerability to inject JS code that  
could scrape the page source for tokens. If those tokens don't expire,  
he can run as many attack actions as he like. The idea behind expiring  
tokens is that he can run each action at least only once, to limit the  
possible damage. This still won't help with stored XSS  
vulnerabilities, but that's a different story. It's not a protection,  
it just makes it harder for the attacker.

> It seems to me our token system should exist to prevent bare URLs in  
> external data from being able to trigger unwanted actions.  But the  
> overhead, and the UI issue of throwing token link errors to the  
> users much more often than we should, seem to indicate that we can  
> get the desired protection by using a single session token rather  
> than using an external system to track multiple tokens.
>
> michael
>
> ___________________________________
> Michael Slusarz [slusarz at horde.org]
>
> -- 
> dev mailing list
> Frequently Asked Questions: http://wiki.horde.org/FAQ
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org

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