ASP.NET Web Forms is not generating a new session ID if a user logs out and logs back in. Is this a major security risk? We're using SSL.

  • What research have you done? Are you familiar with session fixation? Commented May 5, 2016 at 16:11
  • @NeilSmithline wouldn't that only be an issue if the session ID AND data weren't updating correctly in the state machine? As long as the correct checks and balances are in place, this is a maybe scenario. Commented May 5, 2016 at 16:29
  • session fixation as in timeout? Commented May 5, 2016 at 16:50
  • No, session fixation as in it links the session only to the session ID, and not the unique characteristics of the connection. Commented May 5, 2016 at 16:56
  • 1
    Not resetting a session ID sounds like a possibility for session fixation. Just something to test Commented May 9, 2016 at 15:52

3 Answers 3


We should make one thing clear before we move one:

Depending on the setup: Session IDs are not the same as session data

This doesn't mean it's safe, but it also doesn't mean it's unsafe.

Now let's work through the state machine of user sessions throughout the entire transaction and see what happens with the data in the session:

Session begins

Computer navigates to web service, gets session id=X and session data gets stored in DB as id = X, session_data = {"User": null, "IP_address":..., "Mac":..., "Other_device_specific_info":...}

User logs in

User logs in and session data in the database gets updated like UPDATE sessions SET session_data->user = Y WHERE id = X;. The session has been updated to reflect changes and permission changes, but the session ID doesn't need to be updated because it's the same machine, on the same visit.

User does stuff

User does some stuff and the session_data gets updated again, setting other values in it they want to track.

User logs out

Now the user logs out, and the session destroys the data, but keeps the id and makes a new fresh session with that same id because it's the same machine on the same visit and it now looks like id = X, session_data = {"User": null, "IP_address":...} which is identical to the original, non user session.

A different user logs in

Now a different user logs in and we do the same things again.

Eventually the person closes the window/tab

Since the session ID was ephemeral/times out eventually it will get destroyed, and then when that machine visits again it will have a new session ID.

As you can see, as long the back end has been designed correctly, using the same session ID isn't a problem at all. IT(both it and IT) would be a problem if the same session data was reused.

The Bad News

This all assumes that the session data, and id, are tracked correctly and the web service is not vulnerable because of the session ID being associated to the machine and not the user.

Realistically it should change at some point

Things to make sure of

  • Sessions are set up safely
  • Session flow makes sense
  • Session ID != Session data
  • Session data is stored securely

Extra information

  • Sessions are really more of a method and guidelines for storing state based information in some place
  • They can be setup infinitely many safe ways
  • They can be setup infinitely many unsafe ways
  • You're really trusting someone else to have done it right when you use their services, so there are no guarantees

Just because a session ID is linked to a machine and not a user, doesn't mean it's been setup wrong. It just means they're probably also tracking what users have used what machines, for how long for metric purposes.

Things to be aware of just in case

You should probably Google these terms just to make sure your setup is safe

  • Session Fixation
  • Replay Attacks
  • MITM attacks
  • Unsafe connections
  • Forever Sessions
  • Ephemeral Sessions
  • Cookie Session
  • Database Session
  • Redis Session
  • Stateless Web App
  • 1
    ah okay! sorta of like references and pointers in C. Make sense! Commented May 5, 2016 at 16:49
  • Sort of! This is assuming someone set them up correctly in teh first place. There are always vulnerabilities to be aware of Commented May 5, 2016 at 16:51
  • I was thinking the danger was if somehow my cookie data for the session got exposed, it is always tied back to my machine. Commented May 5, 2016 at 16:54
  • Like I said in the bad news part, that's only true if the session is setup correctly and tracks the unique characteristics of the machine. Commented May 5, 2016 at 16:54

In ASP.NET it is normal to reuse a session id. As for the data stored in the session, if you want to make sure that the data cannot be accessed once the user logs out, you can call Session.Abandon() in your logout functionality. But even if you don't call Abandon, the session is no more vulnerable than it is while the user is logged in. Abandoning simply forces it to clean it up sooner than however long it takes for an unused session to expire (I think the default is 20 minutes). It's still a good idea to call Abandon to prevent session hijacking after someone logs out and walks away from a shared computer.

  • 1
    Note that the session ID should also be cleared to prevent session fixation (Response.Cookies.Add(new HttpCookie("ASP.NET_SessionId", ""));), simply abandoning the session is not sufficient. Commented May 9, 2016 at 8:44
  • Actually abandoning is sufficient against session hijacking. Session fixation works regardless of whether or not you use reuse the session id because you are replacing the session id. Session fixation is not an attack against session reuse, and it only applies if you use session for logins (rather than auth tokens) AND you also have another vulnerability on your site that allows someone to replace a current user's session id.
    – TTT
    Commented May 9, 2016 at 14:25

Yes, this could give rise to a session fixation vulnerability.

Say your site is on example.com and you allow users to upload their own pages to usercontent.example.com to guard against Cross-Site Scripting.

You may think that cookies on example.com are safe from any script running on usercontent.example.com because the host-only-flag is set by default on your session cookies. However, an attacker could carry out an attack as follows:

  1. Attacker visits example.com and gets a session ID - she makes a note of it.

  2. Attacker uploads some content to usercontent.example.com including some JavaScript to set a cookie at example.com level to set the session ID to her's.

  3. The attacker incites an admin user at example.com to visit the attacker's page at http://usercontent.example.com/evil_page.

  4. Now the attacker and the victim have the same session ID. The attacker was given the session ID by the server, the victim was given the session ID by the attacker's evil page.

  5. The attacker waits for the victim to login to example.com. As the site does not rotate session IDs, the attacker will also be logged in as an admin.

  6. Voila - a session fixation attack.

Whether this is possible or not with your web forms application depends on whether it uses Forms Authentication or Session ID to track user sessions. See this answer. Forms Authentication generates a new token for each login, so shouldn't be vulnerable. However, if Session is also used and trusted while logged in, then this may also be leveraged by an attacker to maliciously control an admin using session fixation, depending on site functionality.

  • I think you're confusing two different things. The answer you linked to (and I agree with your answer there) was answering a different question: "Is using session state an unsafe way to create user logins and role in asp.net?" Session fixation is a good reason why you shouldn't do that. This question is asking about reusing session IDs (it doesn't say that session is being used for login.) Session Fixation doesn't apply here, because if you use session ID for login, then the fixation attack is valid even if you don't reuse session ids.
    – TTT
    Commented May 9, 2016 at 14:22
  • @TTT: I've covered that in my sentence here: Whether this is possible or not with your web forms application depends on whether it uses Forms Authentication or Session ID to track user sessions.. By the way, for the record I didn't downvote you. Commented May 9, 2016 at 14:26
  • I agree with that sentence. But I disagree with your first sentence (and therefore I think session fixation isn't relevant to this question.) Do you agree with my assertion that session fixation is still possible even if you don't reuse session ids?
    – TTT
    Commented May 9, 2016 at 14:28
  • That is why I said it could give rise. No, I didn't follow that at all - if Session is used to track logins (say Session["User"] = "foo";), and you issue a new Session ID upon login, the attacker will have no idea what the new Session ID is, and therefore cannot fixate the session because there will be a duplicate Session ID cookie (the app could detect this). Additionally, they cannot read it on usercontent.example.com because the new cookie is set with the host-only-flag meaning it won't be sent to that domain. Commented May 9, 2016 at 16:15
  • Ok, that makes sense. Now re-reading your answer beginning to end I agree with you. Since the norm is (or should be?) not to use sessions to manage logins, I think it would be clearer if in your first sentence you said something like: "Yes, if you the use the Session to manage logins, ...". (It won't let me change my DV unless the answer is edited, which is IMHO wrong to assume it needs editing for me to change my mind.)
    – TTT
    Commented May 9, 2016 at 16:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .