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

[Michael M Slusarz]

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