3

I understand that Session object is used to store data per session. I did the following experiment:

  1. Open browser and visit an aspx page A, which saves some data to Session object.
  2. Keep the browser open and open another tab to visit an aspx page B which display the session data. And it displayed just as I stored in step 1.
  3. I close the browser and re-visit the page B, the stored data is gone.

From 3, it seems server side somehow detect that I (the client side) has terminated a session. But as I checked with Fiddler, there's no bits sent to the server when I close the browser in step 3.

So how could the ASP.NET application possibly know my step 3 request is for a new Session?

And how is session defined? Do different tabs always belong to the same session?

ADD 1

Although the session data can be displayed in page A and page B, the session IDs displayed in them are different. Why?

Correct

The session id in page A and page B are the same. I am not using InPrivate browsing.

ADD 2

There's indeed a Cookie for session ID:

ASP.NET_SessionId=lmswljirqdjxdfq3mvmbwroy; path=/; domain=localhost; HttpOnly

It was set when a POST request is responded.

So I did another experiment, I close the browser (Fire Fox) and as expected, the Cookie no longer exist. I manually create the cookie in hope of "the faked Cookie could bring back the old session." But Fiddler indicates that the manual cookie didn't get sent at all.

Fiddler says:

This request did not send any cookie data.

So is it possible to fake a cookie and restore an previous session?

And how long does a session live on server?

smwikipedia
  • 61,609
  • 92
  • 309
  • 482
  • Are you using cookies based sessions? Are you using some kind of in-private browsing? Because what you described is not the standard behavior. Assuming you're using one browser a session is persistent across tabs and the browser being opened and closed, but only if you're using cookie sessions. Using any other type, such as URL appending will cause you to generate new sessions an each visit unless you start with the right URL. – siva.k Jul 16 '14 at 13:49
  • @siva.k isn't standard behavior? usually asp.net session relies on session cookies. they're discarded when browser is closed but they're preserved if you close tab (that's why it's strongly suggested to logout from websites before you close tab, see also [this post about Chrome and its session management on crashes](http://stackoverflow.com/questions/24047058/google-chrome-restores-session-cookies-after-a-crash-how-to-avoid)). on server they'll expire by timeout – Adriano Repetti Jul 16 '14 at 13:53
  • @AdrianoRepetti cookies don't discard when you close the window (assuming not in-private). When you open a browser back up it'll send the last set of cookies back to a site. Otherwise every page you loaded would require you to log back in every time you closed and opened a browser. Using cookie based sessions makes sure that the client will always try to send its identifier back to the server. Without this cookie the server will always treat the request as a new session. And yes session cookies are standard behavior, but what smwikipedia described isn't. – siva.k Jul 16 '14 at 14:00
  • _"usually asp.net session relies on **session cookies**"_. Of course I'm talking about session cookies! AFAIK what OP is describing is standard behavior in every browser I saw. Session cookies are shared across tabs and discarded when window is closed. – Adriano Repetti Jul 16 '14 at 14:01

2 Answers2

8

When the server starts a new session, it generates a new identifier for the session. The session data is stored under this identifier / key in your session provider (can be in-memory, in SQL Server or something else entirely, depending on your configuration - this is usually configured in web.config).

At the same time, the server sends a cookie to your browser (at least in the default setup). This cookie contains the identifier for your session. That is how the server can correlate your requests to your particular session: in every request, your browser will send the session cookie along. The server retrieves the identifier from the cookie and looks up your session data using the identifier.

The session cookie is non-persistent, which means that the cookie will be deleted when the browser is closed. That is why it looks like the session was deleted: the session data still exists on the server, but because the session cookie has been deleted, the browser won't send along a session cookie, so the server will consider this to be the beginning of a new session, create a new session identifier etc. Thus, the server doesn't really know when a session ends, it just knows when a session begins. That is why, in the default SQL Server-backed setup, a scheduled job will purge inactive sessions - otherwise the session data would linger in the database forever.

For more on sessions, using sessions without cookies, session configuration, providers etc., see MSDN.

As to whether sessions are shared between browser tabs: this really comes down to whether cookies are shared between tabs. I think cookies are shared across tabs in all major browsers and I would assume it would be rather confusing if they weren't, but there is nothing preventing someone from creating a browser where cookies aren't shared across tabs.

EDIT 1

If you delete the session cookie, you could in theory recreate your session by recreating the cookie. This is not a security issue per se, because you are recreating data you already have access to. However, if someone else were to recreate your session cookie, that would be a security issue. You can google "ASP.NET session hijacking" if you want to look into this.

EDIT 2

The session basically lives on the server until something purges it. Thus, the lifetime of the session depends on where you store it. If you store it in memory, the session will be deleted when the application is recycled (could be because you recycle the app in IIS or because the server is restarted). If you store it in SQL Server, the session data will live until a job deletes it because it hasn't been accessed for a while (sorry, I don't remember the details, but you can probably google them). If you store your session data in Azure table storage, they will likely never be purged.

Note

Two important details of ASP.NET session state are often overlooked:

  1. When the session is stored outside the process (say, in SQL Server), the data you want to store must be serializable.
  2. To prevent race conditions when accessing the session data, requests accessing the session will be serialized, that is, they will not execute concurrently.

Further details may be found in the MSDN article "Underpinnings of the Session State Implementation in ASP.NET"

Rune
  • 8,340
  • 3
  • 34
  • 47
  • @smwikipedia in this answer there is a link to a pretty comprehensive article. It'll answer all subsequent questions you added to your question – Adriano Repetti Jul 16 '14 at 14:39
1

This article provides more details about ASP.NET Session (http://msdn.microsoft.com/en-us/library/vstudio/ms178581(v=vs.100).aspx)

The idea is simple.

  1. When you visit a page, a session ID is generated and set as a cookie. A timer is started for that session ID too.
  2. As you keep coming back, the timer is reset. If you wait long enough before requesting another page, the timer will expire and your session will not be valid. At that point a new session will be generated.

To Answer your questions: If you open multiple tabs, they will "share" the session. Because your browser is sending the session cookie from all those tabs. However, if you open Firefox and Chrome. These two browsers will not share the session. Since, they don't share cookies.

When you close your browser, your session is still valid. And if you visit a page on the site before the session has expired, you will not get a new session. That is why, it is suggested to always log out. This way the site knows that you're leaving and it will destroy the session on your behalf.

Q: Although the session data can be displayed in page A and page B, the session IDs displayed in them are different. A: Are you sure? The session ID should be the same for all pages. It will be different if you access page A from one browser and Page B from another browser.

ADD2

It is possible your browser's setting is to destroy cookies on windows close. Please double check that in options it's set to remember history.

Cookies can be forged. If an attacker can get the session ID, they can forge a cookie at their end. I'm not sure if Fiddler allows you to create a cookie manually. You will need to dig through the docs. Or maybe someone else here can answer this questions.

Roman Mik
  • 3,179
  • 3
  • 27
  • 49