[mod_python] Re: Secure Sessions patch

Steve Holden wrote ..
> Graham Dumpleton wrote:
> > Daniel Adler wrote ..
> >> Hi,
> >>
> >> I saw there was a discussion on this topic already:
> >> http://www.modpython.org/pipermail/mod_python/2006-May/021260.html
> >> and came up with the same wish -
> >> I want to force a session cookie to be explicitly created for https.
> >>
> >> I have added a "secure" parameter to the session class constructors.
> >> If it is set AND req.is_https(), the cookie will be created wiht "secure"
> >> set.
> >>
> >> A diff of session.py in release 3.2.10 with this feature is available
> on
> >> http://neoscientists.org/~plex/mod_python_3_2_10_session_with_secure_cookie.diff
> > 
> > I'd suggest that an explicit argument to Session.Session() is probably
> > not the best way of doing this. I am also dubious of it only being set
> > if HTTPS is used as that suggests that if first access is not via HTTPS,
> > that one could then continue to access the site thereafter without it
> > needing it to be HTTPS which defeats the purpose of having it in the
> > first place as you want to probably force it to be HTTPS always and not
> > allow HTTP at all.
> > 
> > In place of an argument to Session.Session(), a PythonOption setting
> > would possibly be more appropriate and would then be similar with how
> > other aspects of cookies are configured for sessions. For example:
> > 
> >   PythonOption mod_python.session.secure: 1
> > 
> > By being an option it is easier to apply it to the complete URL
> > namespace for an application, especially if application is coded poorly
> > and doesn't have all session creation performed in one place only, or
> > you can't modify the code for the application easily.
> > 
> > In being set this way, 'secure' should also perhaps always be set,
> > regardless of whether HTTPS is used. The outcome of this is that the
> > client would never send the cookie back if it wasn't HTTPS, thus result
> > would be always being pushed back to the login form (session creation
> > point) if not HTTPS, thereby clearly indicating that something is wrong
> > and also not inadvertently still letting someone in by accident through
> > HTTP.
> > 
> > Another possible issue is whether through Session instance it should
> be
> > possible to access the cookie properties and interrogate if the cookie
> > for a session had the 'secure' attribute. If you don't have a means of
> > validating that it was secure cookie, then someone could modify the
> > cookie on the client side, remove the secure attribute and change from
> > using HTTPS to HTTP and possibly start to reveal information in traffic
> > that you didn't want to be revealed.
> > 
> > On the latter point, one could argue that setting the PythonOption
> > should also be a trigger for the Session class to perform a validation
> > and always reject any cookie that doesn't have the 'secure' flag,
> > presuming that the 'secure' flag is actually sent back with the cookie
> > by the client.
> > 
> I understood that browsers would flag cookies as secure if they received
> them over https, and maintain separation between secure and non-secure
> cookies. I wouldn't expect to see the secure flag represented inside the
> cookie, as the two sets (secure and non-secure) should be disjoint. This
> can cause session maintenance problems when some pages in the session 
> are http and others are https.

When we do work out appropriate way of doing it and what it all means,
for good measure we probably want to allow people to set the 'httponly'
attribute of the cookie for a session as well. I release this is a defacto
standard set by Microsoft rather than a real standard attribute and not all
browsers support it, but someone will probably ask for it at some point.

Graham