[Twisted-web] Session class

[Maarten ter Huurne]

Hi,

I was looking at twisted.web.server.Session recently and the way session 
timeouts work.

The values of sessionCheckTime and sessionTimeout are not tied together in 
any way. This means that if you increase the sessionTimeout, session expiry 
is checked uncessarily often (although one check per 30 minutes is not 
likely to become a performance problem). In the opposite case, sessions 
with a short sessionTimeout will not be expired faster than the 
sessionCheckTime.

The Request.getSession() method does not check whether the session has 
already expired. Also, it calls Session.touch(), so if the session was past 
its sessionTimeout but before the sessionCheckTime, it will be revived.

None of this is a critical problem, but it does feel a bit strange. Is the 
current design motivated by something I haven't understood yet, or is it 
something that works well enough in typical use even though it has some 
unexpected special cases?


While reading the implementation of Session, I was wondering about the 
security aspects of it.

Currently, Request.getSession() returns a cookie that is not marked as 
secure, even if the request was made over HTTPS. This means that for 
example someone in control of a WiFi access point can trick the browser 
into sending the session cookie unencrypted. Is this indeed the case? And 
if so, what is the way to fix it: should people requiring secure cookies 
avoid the Session class, or should a notion of a "secure session" be added 
to the Session class?

I was also wondering about the session UID. This UID is generated from a 
random number (from Python's Mersenne Twister) and a counter. Then an MD5 
sum is computed over the string representation of both. If the same Python 
process uses the same random generator (global instance from the "random" 
module) for outputting non-hashed values as well, an attacker would be able 
to learn the current state of the random generator and predict the next 
random number. Since the counter is also predictable, guessing the next 
session UID would be simple.

Is the UID intended to be secure, or is it only intended to have a low 
chance of collisions with other UIDs?

If it is intended to be secure, one way of fixing it would be to use a 
secure random generator for generating the UID. However, secure random 
generators depend on external entropy, which might take some time to 
acquire. This would make the UID generation a potentially blocking 
operation, which would require Request.getSession() to return the session 
via a deferred instead of directly.

A possible way to reduce UID predictability is to instantiate a random 
generator which is used only for creating UIDs, instead of using a shared 
instance. Since all outputs based on these random numbers are hashed, it 
will be much harder to predict the state of the random generator. My crypto 
knowledge is not sufficient though to say whether this would make it secure 
or just less insecure.

Bye,
		Maarten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part.
Url : http://twistedmatrix.com/pipermail/twisted-web/attachments/20081001/3ba8aaf2/attachment.pgp