[horde] Autologin into Horde

Michael M Slusarz slusarz at horde.org
Tue Apr 16 23:00:32 UTC 2013


Quoting Michael M Slusarz <slusarz at horde.org>:

> I guess another possible option would be to regenerate the session  
> ID after a certain period of time if the client appears to still be  
> active.  This eliminates the security concern of someone recovering  
> the session ID and being able to use it, while allowing us to forgo  
> re-authentication.  However, I don't think the framework is in place  
> for this to work in dynamic applications if not using COOKIES (there  
> may be links present on the page containing the old session ID).   
> But maybe we ignore this use-case, since we already heavily disfavor  
> non-cookie based sessions as it is?

Played around with this idea this afternoon and it seems to work well.  
  At a minimum, it provides some protection against session fixation  
attacks by periodically changing the session identifier in active  
sessions (the regeneration value is either half the maximum session GC  
time, or 1 day if no GC is active).

Cookie based sessions see this value automatically updated in the  
cookie.  Non-cookie based dynamic sessions now send the SID on every  
request in order to catch SID changes.

The 1 DoS issue I can think of is if multiple dynamic requests are  
received at the same time - if the SID changes in the first request  
one of the subsequent cached requests will try to access a  
non-existent session and will cause a logout.  Although...

1) This should be very rare.
2) I'm actually not sure if this will even occur.  Since these  
requests are waiting for R/W access on the session data, the old  
session data may not be deleted until these queued requests are  
completed (likewise, I'm not sure if this will point to the new  
session data or the old session data).  The documentation doesn't  
discuss this in any detail.
3) Although even if PHP behaves in #2, there is still the edge case of  
changing the SID and the request returning the SID to the browser, and  
in between the time session is closed and the new SID is recieved the  
browser fires off a request with the old SID.  Not sure if this edge  
case is worth dealing with.

An option to fix is to create a periodic request from the browser to  
explicitly change the SID that locks out all other requests until it  
is completed.  It could be scheduled to run at a certain time period  
before server-side regeneration would occur to ensure that it always  
occurs under controlled conditions.

michael

___________________________________
Michael Slusarz [slusarz at horde.org]



More information about the horde mailing list