Hi Koen, Yeah I agree, for witty sessions, it needs to be a config file option as there's no real way to know how it's deployed inside the code.
That patch just adds the option to make user cookies secure .. it doesn't actually do anything to witty session cookies. httpOnly looks very good too. I'll add it to that patch later tonight and repost. Later you/I/we can prolly make another patch built on top of this one that enables witty session cookies to be 'secure' and 'httpOnly'. ---- With my current app, I'm writing my own logged in user session manager, which uses custom cookies (per your suggestion) and lives longer than witty sessions. In the future, I'd like to see Witty sessions not die when using html5 history and people typing straight in the address bar. Do you think that's a possibility ? Otherwise, I'll be happy to contribute my (longer than witty) session manager code once it's working nicely. I'm using boost thread stuff so that multiple threads can safely read the session data. Kind Regards, Matthew Sherborne On Thu, Jun 23, 2011 at 6:10 PM, Koen Deforche <[email protected]> wrote: > Hey Matthew, > > 2011/6/23 Matthew Sherborne <[email protected]>: >> Hi guys, >> >> I read these slides on how to hack sites that don't set the 'secure' >> flag on their cookies: >> http://fscked.org/blog/fully-automated-active-https-cookie-hijacking >> >> So as I'm working on a 'logged in user session' thing that outlives >> witty sessions. I've added this patch to wt git master. > > I agree with the general thought of this patch. > > I also think that if the developer wants to set a "secure" cookie, the > cookie should only be set if a secure connection is being used. > > The only problem is that not in all circumstances, Wt knows whether > the request comes over a secure connection. When using FastCGI or > ISAPI or when deployed (e.g. with the built-in httpd) behind a reverse > proxy that acts as an OpenSSL terminator, we would wrongly assume that > the connection is not secure. So it would need something that can be > configured/customized, but the default behaviour of looking at the > used schema (http versus https) would at least not be unsafe. > > While reading up on the Secure option, I've also come across HttpOnly > which I believe we should always set. > > Regards, > koen > > ------------------------------------------------------------------------------ > Simplify data backup and recovery for your virtual environment with vRanger. > Installation's a snap, and flexible recovery options mean your data is safe, > secure and there when you need it. Data protection magic? > Nope - It's vRanger. Get your free trial download today. > http://p.sf.net/sfu/quest-sfdev2dev > _______________________________________________ > witty-interest mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/witty-interest > ------------------------------------------------------------------------------ Simplify data backup and recovery for your virtual environment with vRanger. Installation's a snap, and flexible recovery options mean your data is safe, secure and there when you need it. Data protection magic? Nope - It's vRanger. Get your free trial download today. http://p.sf.net/sfu/quest-sfdev2dev _______________________________________________ witty-interest mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/witty-interest
