Session Management with Windows Authentication

Question

In an ASP.NET web app, using Integrated Windows Authentication, is the session tied to the windows identity?
In other words, if I login (using IWA) to the app, and the app stores some "stuff" in my session, is this stuff accessible by session id alone? For instance, if a malicious someone managed to steal my session id, but NOT my credentials, can he then access my session stuff? Or is this session accessible only to the same identity, requiring both the session id AND the windows identity to access it?

Dolhenty

Answer 1

Excellent question. I just ran a test to confirm before i wrote this answer.

If i am 'Person A', and you are 'Person B', then this is what has to happen:

• Person A logs in to the website using IWA, gets assigned a session id (for example, in the url)
• Person B also logs in to the website as themselves (so they have to be authenticated)
• Person A sends Person B a url link that contains a session identifier
• Person B clicks on that link, they get taken straight into the web site, using the session details of Person A

Note that Person B is still recognised as 'Person B' by the website, even though they are using Person A's session details. So if you have code that checks user permissions etc, then those checks are still done in the context of Person B.

This might sound like a huge issue, but it isn't really as long as the programmers are not careless. For instance, the only effect that Person B got in my test above was that they inherited the screen and grid layouts that Person A had set up, because we do our permission checks live (i.e. they are not cached). If you store sensitive data in the session then it could be a problem, but it is only a problem if they fields showing it are not permission checked every single time they are shown. It's also only an issue if the session for Person A hasn't expired.

Siddon

Nice example of a more "innocent" scenario :). So you're saying that the session and the authentication have nothing to do with each other? That is odd... And it's actually quite common to store roles, or some other authorization token, in the session, which would make this issue critical in this scenario. Thanks. – Dolhenty