So I’m running into an interesting issue implementing session ID rolling after log-in/change of access levels/etc.
On log-in I’m currently trying to generate a new session ID using the SessionIDManager, however this only changes the cookie header, it doesn’t swap out the session in HttpContext, so as I add additional details to the session (various details to bind the user to the session ID), they immediately get lost (not to mention the old session gets abandoned).
To prevent session hijacking (by storing primary non-SSL communication) and session fixation, we should generate a new Session ID upon log in, but Microsoft doesn’t seem to allow you to do that (grr, so many read-only variables and sealed classes with no constructors). I could just migrate all data in the backend SQL, but that seems a bit “dirty hack”.
Any ideas on how to properly do this?
Edit:
Implementations I’ve found:
Session.Abandon();
Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));
Session still is the old session, so on next page, all changes are lost.
SessionIDManager doesn’t return a session object after SaveSessionID, so I cannot add details to the session I just created. On the next page load I can, but the old session is now inaccessible (and abandoned, but even if it wasn’t abandoned…).
HttpContext.Session is read only, even if it wasn’t, HttpSessionState doesn’t have a constructor.
Edit 2:
Apparently session fixation and hijacking have been talked about before here, with the answer being “Microsoft doesn’t seem to care”, with a poorly implemented two-phase fix.
Alright, so this is a bit of an issue, showed how you can hijack session based auth AND forms based auth using this method (you’ll need a valid user account, but you can hijack someone else’s session), there are some blogs online that complain about session fixation and the ability to easily exploit hijacking. So obviously this is a huge issue. Yahia pointed out Microsoft isn’t interested in fixing this.
What I did was create an authenticity key that got paired with the session ID, upon log in we’d generate a new one and put it in the session and give the user a cookie, if there was a key in the session they must match, if not we’d kick the user (hijacking attempt). It seems to be a common way to do this on the blogs mentioned (another is to use forms auth to basically encrypt the cookie, while this works fine I wanted the solution to be compatible with multiple types of authentication).
One thing that was recommended that could help is to prevent any non-ssl communication by using another application as the non-ssl front end that just serves 302 redirects, as recommended by Yahia, while this helps a ton by preventing the disclosure of the session IDs in the first place, it would require a lot of restructuring of how the applications are deployed to fix, and IMO: .NET’s iffy session management should be fixed in the first place, and I wanted our applications to be fully secured from the ground up, not dependent on other applications to do 302 redirects so that any information leakage is irrelevant being as the cookie will rotate on log in.