|
Steve Holden
steve at holdenweb.com
Mon Dec 18 13:11:51 EST 2006
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. > Thus, I can seem merit in what you are trying to achieve, but it perhaps > needs some more thought as to how it should be achieved to ensure that > there aren't back doors in the way it is done. > I agree that the proposed solution was a bit lame, though in the right spirit. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden
|