Anthony: I don't really understand how would that solve the problem. The problem has to do with transmission of the session cookie in a non secure channel. Regenerate it won't solve the problem. We need to enforce not to allow the transmission of authenticated sessions threw non secure channels. I think this should be the default behavior.
pbreit: this is a real issue. Facebook, Twitter and Google Mail are doing this as they acknowledged the problem. If you need proof of concepts and you can get it easily with a simple firefox extension that performs this attack called "Firesheep". I think the solution requires to automatically redirect this data to be transmitted over HTTPS and not even support logins and authenticated sessions over non secure channels to prevent people's mistakes. Makes no sense to allow logins and show login forms in a non secure channel while there is a secure one. There is no need to change anything in non authenticated sessions because they only provide, by design, publicly available data so there we are ok. Now, I know Massimo will probably not change this default behavior because of backward compatibility (even though this is a real problem requiring a fix) but that doesn't prevent us from making some option/ argument that will automatically enforce this behavior for an entire application (at least) when activated. What do you think? Francisco On Jun 16, 9:43 pm, Anthony <abasta...@gmail.com> wrote: > On Thursday, June 16, 2011 3:04:06 PM UTC-4, Richard G wrote: > > > Someone please correct me if I am wrong, but this issue is one of > > architecting your applications/environment properly. > > > If you only ever use https (ie: no http) then all is fine. > > > If you use mixed http & https, then you likely want to set session.secure() > > (this will set the cookie 'secure' attribute, identifying that the browser > > should never send the cookie over a non secure channel). > > The issue is that first connection you use to obtain the cookie. If it is > > over a non secure channel, the server will send you a cookie with your > > session id and the secure attribute set. This is an issue in that a 3rd > > party can acquire your session id over this nonsecure channel. > > > Solution: Unfortunately the cookie is sent whether you are authenticated or > > not... I believe the only solution is to ensure all web2py calls are over a > > secure channel. Your settings can still identify that other calls may not be > > over secure channels though (think static files, etc... in which you bypass > > web2py). > > Maybe we should also have something like session.regenerate(), which could > optionally be called by session.secure(). This would regenerate the session > ID (but keep the existing session). So, upon login, you could call > session.secure(regenerate=True), and it would change the session ID and > secure the cookie. Would that work? > > Anthony
