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
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:
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.
