Regenerate session identifier

[wedens]

To avoid session fixation attacks it is good practice to generate new session identifier when privileges changed.
It'd be nice to have this feature in wai-session. basically it should assign new identifier and copy all session data.

[singpolyma]

Since the middleware is entirely cookie-based, fixation should not be possible. Additionally, not every wai-session backend uses session ids (for example, https://hackage.haskell.org/package/wai-session-clientsession)

Though it would be pretty easymaybe possible to change the backends I maintain (the demo one in this repo and also https://hackage.haskell.org/package/wai-session-tokyocabinet) to just regenerate the session id on every single request.

[wedens]

It is possible for cookies: https://www.owasp.org/index.php/Session_fixation
so, is it backend responsibility to do this? but how can backend set new cookie value?

[singpolyma]

It is possible for cookies

With XSS, sure

so, is it backend responsibility to do this?

Yes, definitely. If you look at https://github.com/singpolyma/wai-session/blob/master/Network/Wai/Session/Map.hs#L31 for example, you will see it does return k If instead it moved the data over to a new key and then returned that new key, it would be doing what you ask.

[wedens]

ok. I'll leave it as feature request for Map backend then :)

[hce]

So the backend can create a new cookie; however, there is no way for the application to signal the backend a new cookie is required. I've created a workaround for this in the wai-session-postgresql backend, but it is not too pretty. (See https://hackage.haskell.org/package/wai-session-postgresql-0.1.1.0/docs/Network-Wai-Session-PostgreSQL.html#v:clearSession)

IMHO a solution to this would be to extend wai-session to allow an arbitrary number of functions to be passed from the session backend to the application.

[singpolyma]

@hce I guess generating a new id every time would be expensive for your backend, since you would need a db query to update it every time? What if we add a new, future-extensible action along with the get and set actions that is ManagementAction -> m () with data ManagementAction = GenerateNewSessionID and then we have room to add other signals to the backend in the future?

[hce]

I've tried generating a new ID for each request. This unfortunately fails when multiple AJAX requests are sent in parallel.

IMHO it'd be nicer if the "management actions" depended on the used session backend. For example, "GenerateNewSessionID" does not make sense for a client side session store, and would generate a runtime error or be silently ignored (possibly resulting in a security problem, depending on how the session store is used).

[singpolyma]

I assumed silently ignored, yes. Ideally apps using a wai-session should be as backend-agnostic as possible (since that is the point of wai-session).

Perhaps instead of low-lever "management actions" it should be a way to notify the backend of a possibly-relevant state change (such as "priviledges changed") so the backend can decide how to act appripriately

[hce]

That sounds good to me. ATM I can only think of two state change notifications:

• PrivilegesChanged
• SessionNoLongerRequired (declarative way of saying "expire the session!")