Can ASP.NET Session ID be the same on two machines at the same time?

Question

I have an ASP.NET application that uses Session.SessionID to prevent multiple users viewing the same data at the same time.

I have a table that contains a set of images (stored in BLOB) that require processing. Only one user is supposed to be able to view the same image at the same time. To achieve this, as each record is retrieved by a user the record is updated with the Session.SessionID. This update occurs inside a ReaderWriterLock.

I have done a test to ensure the ReaderWriterLock is working correctly and can confirm that only one session can execute the code inside that block at once.

My current theory is that two different users are getting the same SessionID at the same time. A user of this application is allowed to view records they have locked or any unlocked images.

I have modified the application to display the SessionID in the footer of every page so that if the problem happens again I can check the SessionID value.

I've seen some articles online suggesting that SessionID is not unique and some saying that the SessionID is unique. I understand that SessionID is not unique forever but can the SessionID value be considered unique for active sessions?

This forum describes a similar problem

I have also read some suggestions that a Guid should be stored in the Session object and used as a unique ID instead of the Session ID.

Thanks for the responses so far. Here is a clarification based on the answers so far:

"Locked forever" - we prevent this by a lock timeout of 5 minutes. Before a user locks an image, while inside the ReaderWriterLock, we do a "cleanup" of old locks (which unlocks images locked for more than 5 minutes), a query to get the oldest unlocked image and an update statement to "lock" that image to the current session.

A possible cause of the problem would be if one user "locks" an image but then leaves the PC for a short break. If they did nothing for 5 minutes, that image on there screen would be unlocked and potentially opened by another user. I mentioned this scenario when the problem was reported and I was assured that the users had been working continuously.

"Different Window/Tab" - I haven't actually seen the error with my own eyes but the person who reported the problem has told me that it is two different PC's and two different usernames of the logged in user.

Hopefully now that I am displaying the Session ID on the page, next time it happens I will be able to say with certainty whether it is the same Session ID on two machines or if it is some other problem. This issue has never occurred during the testing phase so it appears to be a symptom of a larger number of concurrent users.

Thanks for the responses so far and I will update this question as more information comes to hand.

It seems that the user didn't give me the full story. Session ID is unique in our case as per the accepted answer. Two users were able to see the same image at the same time because user 1 was idle for the 5 minute "abandoned image" unlock process. The "abandoned image" timeout has been raised to match the session timeout to avoid this problem.

Answer 1

This link says session ids are unique - http://support.microsoft.com/kb/899918

Session ids are unique in that only 1 session will ever have that id at any given time.

If this wasn't the case I think there would be a lot of people shouting very loudly about it.

Answer 2

The Session ID is almost certainly unique to the user. Failure modes where several users share a SessionID are very, very rare today. However, a user can do several things to create the effect you are seeing.

For instance the user can have several tabs open in her browser. Those tabs will all share the same Session ID. So if she switches back and forth between those browser tabs it might give the effect you are seeing.

Another issue is that users frequently doubleclick buttons and links. This means a processing request may get issued twice with the same Session ID. I would check for this possibility first.

Answer 3

Session ID is unique per user as far as ASP.NET assigns them, though that is not a guarantee against malicious users (a user could manually copy the ID they've been assigned and give it to someone else).

What you are likely seeing here is multiple tabs or windows from the same user, as it is perfectly valid for a user to be making more then one request at a time.

To do what you want I would have to ask - how do you know when a user has stopped looking at an image, so you can unlock it. What if I view an image, and then just close my browser instead of going to another page/image, does it remain locked to my (lost forever) session id?

If you are using some kind of checkout scheme - the user must intentionally check out and check in an image, then you should perhaps be using a unique number for that checkout (new Guid), rather then the whole user.

Answer 4

Red flag here people.

Yes you can but it's absolutely essential that you can't or at the very least make it as difficult as possible to re-use them in the future.

This is dependent on how well your server side application is handling Session ID's and maintaining State. You should (actually MUST) think about limiting session_ID lifetime, how you look after authentication /authorisation state.

I saw in a critical trading platform at a top 10 investment bank whereby you could capture Session ID's on the fly (that contained authorised permissions) and re-use them (through a tool such as Paros from ParosProxy.org) to perform $multi million trades on someone else's behalf. In the current climate - is this an issue? ;-) Sorry - as much as I'd love to name & shame these clowns, I won't.

How likely is this scenario? Can you capture Session ID's on a Switched Network? Certainly within a local VLAN using the hacking tool CAIN and taking advantage of ARP poisioning you can.

In a poorly written Server Side application, you can also predict Session ID's. Check the tool WebScarab (which is in any Pen Testers armoury). This will detect the randomness of ID's. At the same bank with another critical application you could generate your own Session ID's to access & trade applications. Their focus was on low latency (which is business critical) rather than Security.

An intro can be found at Owasp.org

Noelie Dunne