Friday, March 13, 2009

ASP.NET Cookieless Session [Pros & Cons]


Enter Cookieless Sessions

you don't have to change anything in your ASP.NET application to enable cookieless sessions, just enter sessionState cookieless="true" in your web.config.

Internal Implementation of Cookieless Session in ASP.NET

The implementation of cookieless sessions includes couple of runtime modules:

1.   1. SessionStateModule [A standard session HTTP Module]
 2. Aspnet_filter.dll [Works as an executable]

Once the HTTP Request come at the server, a small piece of Win32 code works as an ISAPI filter. HTTP modules and ISAPI filters are in opinion of the same concept, except that HTTP modules are created by the managed code and require ASP.NET and CLR to trigger and work. Classic ISAPI filters like aspnet_filter.dll are invoked by IIS. Both capture IIS events fired during the processing of the request.

When the first request of a new browser session comes at server to process, the SessionStateModule reads about the cookie support in the web.config file [By default “machine.config” specifies cookie enabled session]. If the “cookieless” attribute of the  section is set to true, the module generates a new session ID, twists the URL by appending the session ID just before the requested page name, and redirects the browser to the newly created URL using the “HTTP 302 command”.

When each request reaches at the IIS boundary—far before it is handed over to ASP.NET—aspnet_filter.dll is given a chance to look at it. If the URL appends a session ID in parentheses, then the session ID is extracted and copied into a request header called AspFilterSessionId. The URL is then rewritten to exactly like the originally requested resource and let go. This time the ASP.NET session state module retrieves the session ID from the request header and proceeds with session-state binding.

The cookieless mechanism works great as long as the URL contains information that can be used to obtain the session ID. As you'll see in a moment, this poses some usage restrictions.

Let's review the pros and cons of cookieless sessions.

Advantages of Cookieless Session

In ASP.NET, session management and forms authentication are the only two system features that use cookies under the hood. With cookieless sessions, you can now deploy stateful applications that work regardless of the user's preferences about cookies. As of ASP.NET 1.x, though, cookies are still required to implement forms authentication. The good news is that in ASP.NET 2.0 forms authentication can optionally work in a cookieless fashion.

Another common reason advanced against cookies is security. This is a point that deserves a bit more attention.

Cookies are inert text files and as such can be replaced or poisoned by hackers, should they gain access to a machine. The real threat lies not much in what cookies can install on your client machine, but in what they can upload to the target site. Cookies are not programs and never run like programs; other software that gets installed on your machine, though, can use the built-in browser support for cookies to do bad things remotely.

Furthermore, cookies are at risk of theft. Once stolen, a cookie that contains valuable and personal information can disclose its contents to malicious hackers and favor other types of Web attacks.

Disadvantages of Cookieless Session

By looking the advantages of cookieless session we should not reach on any conclusion: Considering security aspect, your cookieless sessions are easier to hack in compare. Session Hijacking can act against this approach.

In brief, session hijacking occurs when an attacker gains access to the session state of a particular user. Basically, the attacker steals a valid session ID and uses that to get into the system and snoop into the data. One common way to get a valid session ID is stealing a valid session cookie. That said, if you think that cookieless sessions put your application on the safe side, you're deadly wrong. With cookieless sessions, in fact, the session ID shows up right in the address bar

With cookieless sessions, stealing session IDs is easier than ever.

Using cookieless sessions also raises issues with links. For example, you can't have absolute, fully qualified links in your ASP.NET pages. If you do this, each request that originates from that hyperlink will be considered as part of a new session. Cookieless sessions require that you always use relative URLs, like in ASP.NET postbacks. You can use a fully qualified URL only if you can embed the session ID in it. But how can you do that, since session IDs are generated at run time?

The following code breaks the session:


To use absolute URLs, resort to a little trick that uses the ApplyAppPathModifier method on the HttpResponse class:

    href= >Click

The ApplyAppPathModifier method takes a string representing a URL and returns an absolute URL that embeds session information. For example, this trick is especially useful in situations in which you need to redirect from a HTTP page to an HTTPS page.


Google Talk Hacks

You can edit most settings by opening regedit and by selecting HKEY_CURRENT_USER/Software/Google/Google Talk.
Accounts: This one has subkeys for different accounts that has logged in on the your PC. These keys have different values that store the username, password and connection options.
Options: This is the most interesting part of GTalk, where most of the current hacks should be used.

1. HKEY_CURRENT_USER\Software\Google\Google Talk\Options\show_pin If "1", shows a "pin" next to the minimize button that keeps the windows on top of all the other open windows when clicked.

2. HKEY_CURRENT_USER\Software\Google\Google Talk\Options\view_show_taskbutton If "0", hides the taskbar button, and leaves the tray icon only, when the window is shown

3. HKEY_CURRENT_USER\Software\Google\Google Talk\Options\away_inactive If "1", status will be set as Away after the specified number of MINUTES.

4. HKEY_CURRENT_USER\Software\Google\Google Talk\Options\away_screensaver If "1", status will be set as Away after the specified number of MINUTES.

5. HKEY_CURRENT_USER\Software\Google\Google Talk\Options\inactive_minutes Number of inactive MINUTES to become away if auto-away is on.

Use multiple-identities with GTalk:

1. Right-click on the desktop
2. Select New
3. Select Shortcut
4. Paste this into the text box: ("C:\Program Files\Google\Google Talk\googletalk.exe" /nomutex )
5. Click Next and choose a shortcut name like "GTalk New Instance".
Here you go.... try to execute this newly created short-cut and use your alternate GTalk ID.

/nomutex, which allows you to run more than one instance of GT.
/autostart, when Google Talk is run with this parameter, it will check the registry settings to see if it needs to be started or not. If the "Start automatically with Windows" option is unchecked, it won't start.
/forcestart, same as /autostart, but forces it to start no matter what option was set.
/S upgrade, Used when upgrading Google Talk
/register: registers Google Talk in the registry, includig the GMail Compose method.
/checkupdate: check for newer versions
/plaintextauth: uses plain authentication mechanism instead then Google's GAIA mechanism. Used for testing the plain method on Google's servers.
/nogaiaauth: disables GAIA authentication method. The same as above.
/factoryreset: set settings back to default.
/gaiaserver uses a different GAIA server to connect to Google Talk. Used for debug purposes only, there are no other known GAIA servers.
/mailto send an email with Gmail
/diag: start Google Talk in diagnostic mode
/log: probably has something to do with the diagnostic logging

To add these, open up your GTalk shortcut, and where it says "Target:" add one or more of these inside the quotations, but after the .exe part