On Mar 15, 2011, at 11:33 AM, Massimo Di Pierro wrote: > > Right now the session is a combination of client ip and a uuid. The > uuid prevents session hijacking. > > The ip serves two purposes: > - the server can find expired sessions more easily > - the apps the reject sessions coming from wrong ip thus further > protecting against hijacking.
Right, but I was referring to Corne's mechanism: > We tried to set a session_id our self based on information in the url, > which in this case resulted in calling the session connect code (where > it went wrong) twice per request. Unless there's a secret key or hash or something in the URL (like the newish hash logic in URL()), this seems open to hijacking. > > On Mar 15, 11:55 am, Jonathan Lundell <jlund...@pobox.com> wrote: >> On Mar 15, 2011, at 7:15 AM, Corne wrote: >>> We (again) looked deeper into what is really happening; and it is yet >>> different. >> >>> What we ran into is the following: >>> We tried to set a session_id our self based on information in the url, >>> which in this case resulted in calling the session connect code (where >>> it went wrong) twice per request. >> >>> In case a cookie was send; there is no problem at all. >>> Session is handled by web2py like always (except for the fact that >>> it's done twice). >>> In case there is no cookie send; there is a problem. >>> The first call to connect (web2py internal) has no session_id, so a >>> new one is generated. >>> The second call to connect (our plugin) has a session id so it's >>> handled ok. >> >>> In the end of the request, the session changes are written. But in our >>> case (without cookie) the var session_new is True (and the session >>> file is (re)opened with 'wb'). >>> Opening with 'wb' does seem to change the file handle. The request >>> that is handled by a differend process at the same time will now have >>> an invallid session. >> >>> This also explains the fact that reopening the session file seemed to >>> solve the problem except for the fact that the real problem is >>> somewhere else. >> >>> I guess that using connect is something that is / should be allowed >>> (it's in the book), this is also the way to, for example use sessions >>> from an other application. >>> and there the same issue could apply: >>> in case someone uses connect to just use a session from a different >>> application. The first connect from web2py might result in creating a >>> new session. While the connect which is issued later by the user does >>> result in an existing session. >> >> When you set your own session_id, does the corresponding session file always >> exist? If it does not, session.connect is going to discard that session_id >> and generate a new uuid. I don't see a way to force session.connect to >> create a session file with a predetermined id. >> >> If that's not an issue, you could try setting response.session_new = False >> before calling session.connect; session.connect probably ought to do that >> itself at the beginning of the not-db logic branch. We could also add a >> session-id argument to allow the caller to force an id, I suppose, but I'd >> like to be a little clearer on your use case. >> >> Doesn't creating a session id based on the request url open up a session to >> hijacking?
