ASP. NET without cookies-ASP. NET session management without cookies: Risks and benefits

ASP. NET without Cookie -- ASP. NET session management without COOKIE: risk and benefit Release Date: 7/18/2005 | Updated on: 7/18/2005

Dino esposito
Wintellect

Abstract:Dino explores the advantages and disadvantages of cookieless sessions and discusses why to avoid storing valuable information in the session state.

Content on this page

	Is cookies a problem?
	Enter a cookieless session
	Implementation
	Advantages
	Disadvantages
	Summary

We acknowledge this-we are so accustomed to the concept of session state that we forget that session state was introduced by Active Server Pages (ASP) in 1997. Session status enables developersProgramDuring the interaction period, a piece of information about the user is permanently saved. User-specific information is usually retained for a period of 20 minutes, and the timer starts every time the user returns to the site.

When a user connects to the site for the first time, a new session state will be created in the form of a memory block to store data. At the same time, an ID is also created to uniquely associate it with the current user. When a request is sent, the user is requested to submit the session ID to retrieve and correctly restore the session status. Session ID is a fully-self-generated alphanumeric string between ASP and ASP. NET. How do users manage it and ensure that it is packaged with every subsequent request?

The nature of the HTTP protocol is stateless and no one attempts to change it. Almost two decades ago, when Netscape corporation developed its first browser, it "invented" a persistence mechanism that works over HTTP. It calls it an HTTP cookie. Interestingly, the term "cookie" in the computer science industry only represents an opaque piece of data held by an application, which affects users but will never be directly managed by users.

Therefore, the cookie stores the session ID, while the browser moves the content back and forth between the Web server and the computer of the local user. When a browser with cookies enabled receives a response packet, it searches for additional cookies and stores their content in a text file in a specific folder in the local Windows directory. The cookie also contains information about the source site. Next, when the browser sends a request to the site, it searches for the cookie from the domain in the cookie folder. If yes, the cookie is automatically appended to the outgoing data packet. The cookie hits the server application and is detected, extracted, and processed here.

In the end, cookies make Web sites easier to navigate, because they provide the illusion of continuity that inevitably spans multiple requests over the user experience.

Is cookies a problem?

For many years, cookies have only been regarded as a technical feature and are largely ignored. A few years ago, the wave around the world targeting Web security focused on cookies. Cookies are determined to contain dangerous programs that can even steal valuable information beyond the physical boundaries of computers.

It is self-evident that cookies are not programs and therefore cannot collect any information on their own-not to mention any personal information about users. More clearly, cookies are a piece of text that can be stored on users' computers for future retrieval and reuse. The stored information is composed of harmless name-value pairs.

The point is that cookies are not part of the standard HTTP specification, so they mean a collaboration between browsers and web sites. Not all browsers support cookies, and more importantly, not all users enable cookie support in their own browser copies.

In history, some web site functions are so closely related to cookies that it is difficult to tell which function is the first to appear. On the one hand, it is much easier to use cookies to encode session Status management and user identity authentication. On the other hand, if you observe the statistics related to the browser used to access the page, you may be surprised to find that a considerable number of users disable cookies during connection. This will inspire developers.

All in all, cookies are not a problem, but their use is undoubtedly given to some servers.CodeThe ability to store a piece of data in a client computer. This indicates some potential security risks and an unsatisfactory overall situation. (In some cases and in some countries, applications require cookies to work or even be illegal .)

Back to Top

Enter a cookieless session

In ASP. NET, You can selectively establish necessary session-user contacts without using cookies. Interestingly, except for the following configuration settings, you do not need to change anything in the ASP. NET application to enable cookie-free sessions.

 
<Sessionstate cookieless = "true"/>
 

The default settings of ASP. NET session status are defined in the machine. config file and can be rewritten in the web. config file in the application root folder. You can enable the cookieless session by ensuring that the preceding row appears in the root web. config file. That's it-simple and effective!

<Sessionstate>Nodes can also be used to configure other aspects of session Status management, including storage media and connection strings. However, for cookie, you only needCookielessSet the property to true (the default value is false ).

Note that session settings are the application scope settings. In other words, the pages on your site either use or do not use cookies to store session IDs.

Where does ASP. Net Store session IDs when no cookie is used? In this case, the session ID is inserted to a specific location in the URL. Displays a snapshot of a real site that uses a session without Cookie.

Figure1.NoneCookieSessionMappoint

Assume that you have requested a page similar to http: // yourserver/folder/default. aspx. As you can see from the mappoint snapshot, the adjacent slashes in front of the resource name are extended to include the brackets filled with the session ID inside, as shown below.

Http: // yourserver/folder/(session ID here)/default. aspx
 

The session ID is embedded in the URL and does not need to be permanently saved anywhere else. Well, not exactly. Consider the following solutions.

You access a page and are assigned a session ID. Next, you clear the address bar of the same browser example, go to another application and start working. Then, you re-type the URL of the previous application and (guess) retrieve the session value as you enter.

If you use a cookieless session, when you access the application for the second time, you will be assigned a different session ID, and all previous statuses will be lost. This is a typical side effect of cookieless sessions. To understand the cause, let's further explore the implementation of cookieless sessions.

Back to Top

Implementation

The implementation of cookieless sessions is benefited from the efforts of the following two runtime modules:SessionstatemoduleAnd an executable file named aspnet_filter.dll. The latter is a short Win32 code that acts as an ISAPI filter. The HTTP module and ISAPI filter share the same idea. The difference is that the HTTP module consists of managed code and can only work after ASP. NET and CLR are triggered. Traditional ISAPI filters such as aspnet_filter.dll are called by Internet Information Service (IIS. Both of them intercept IIS events triggered during request processing.

When the first request for a new browser session enters, the session Status Module reads the cookie-supported settings in the web. config file. IfCookielessIf the attribute is set to true, the module generates a new session ID, which is used to separate the URL by filling the session ID in the adjacent position before the Resource Name, use the HTTP 302 command to redirect the browser to the new URL.

When each request arrives at the IIS portal (much earlier than it was handed over to ASP. NET), aspnet_filter.dll gets a chance to view it. If the URL embeds the session ID in parentheses, the session ID is extracted and copied toAspfiltersessionidIn the request header. Then, rewrite the URL to make it look like the original requested resource and release it. This time, the ASP. NET session status module retrieves the session ID from the request header and continues working through session-status binding.

As long as the URL contains information that can be used to obtain the session ID, the cookie-free mechanism can work well. As you will see later, this will cause some restrictions.

Let's take a look at the advantages and disadvantages of cookieless sessions.

Back to Top

Advantages

In ASP. NET, session management and form authentication are the only two system functions that use cookies in the background. With cookieless sessions, you can now deploy stateful applications that work normally regardless of your cookie preferences. However, for ASP. NET 1.x, you still need to use cookies for form authentication. The good news is that in ASP. NET 2.0, form authentication can work in a non-Cookie manner.

Another frequently raised objection to Cookie is security. This is a key point worth more attention.

Cookies are text files that are incapable of being active. Therefore, these files may be replaced or damaged by attackers-as long as they have access to computers. The real threat lies not in what cookies can be installed on the client computer, but in what they can be uploaded to the target site. Cookies are not programs and will never run as they do. However, other software installed on your computer can use built-in support for cookies to remotely engage in destructive activities.

In addition, cookies are at risk of being stolen. Once stolen, cookies containing valuable and private information may leak their content to malicious attackers and facilitate other types of Web attacks. In short, by using cookies, you can expose yourself to the risks that can be eliminated. Is this true?

Back to Top

Disadvantages

Let's examine security from another perspective. Have you ever heard of session hijacking? If not, read technet magazineArticle Theft on the Web: Prevent session hijacking. In short, session hijacking occurs when attackers obtain access to the session Status of a specific user. In essence, attackers steal valid session IDs and use them to intrude into the system and snoop data. A common method for obtaining valid session IDs is to steal valid session cookies. In view of this, if you believe that cookie-free sessions protect the security of your applications, then you are completely wrong. In fact, for non-Cookie sessions, session IDs are directly displayed in the address bar! Please try the following operations:

1.	Connect to a Web site that uses a cookieless SESSION (for example, mappoint) and obtain a ing. The address is stored in the session state.
2.	Capture the URL (until the Page name ). Do not include query strings, but make sure that the URL contains session IDs.
3.	Save the URL to a file and copy/send it to another computer.
4.	Open the file on the second computer and paste the URL to the new browser instance.
5.	The same ing is displayed as long as the session times out.

Cookie-free sessions allow you to steal session IDs more easily than ever before.

From a moral point of view, session theft should be condemned. I believe everyone will agree with this. But is it harmful? This depends on the content actually stored in the session state. Stealing session IDs does not execute operations beyond the control of the Code. However, it may expose private data to unauthorized users and enable some bad guys to perform unauthorized operations. For more information about how to prevent session hijacking in ASP. NET applications, seeWicked code: foiling session hijacking attempts. (Moreover, it does not rely on cookieless sessions !)

Using a cookieless session will also cause connection-related problems. For example, you cannot have an absolute, fully qualified link on an ASP. NET page. If you do this, each request originating from the hyperlink will be considered part of the new session. Cookie-free sessions require that you always use relative URLs, just as in ASP. NET sending. Only when you can embed a session ID into a URL can you use a fully qualified URL. However, since the session ID is generated at runtime, how can you achieve this?

The following code interrupts the session:

 
<A runat = "server" href = "/test/page. aspx"> click </a>
 

To use an absolute URL, you can use the following tips:HttpresponseClassApplyapppathmodifierMethod:

 
<A runat = "server" href = <% = response. applyapppathmodifier ("/test/page. aspx") %> click </a>
 

ApplyapppathmodifierA URL string is used as a parameter, and an absolute URL embedded with session information is returned. For example, this technique is especially useful when you need to redirect from an HTTP page to an HTTPS page. Finally, note that every time you type a path to a site in the same browser, you will lose the cookie-free session status. Please note that for mobile apps, if the device cannot process specially formatted URLs, the non-Cookie session may be faulty.

Back to Top

Summary

The main reason for the existence of cookieless sessions in ASP. NET is that users (for whatever reason) may disable cookies in their browsers. If your application requires session status, you must face this situation whether you like it or not. A cookieless session embeds the session ID in the URL and returns a double result. On the one hand, they provide a way for the web site to correctly identify the user sending the request. However, on the other hand, they enable session IDs to clearly display in front of potential attackers, so that they can easily steal them and perform operations as you are.

To enable cookie-free sessions, you do not need to modify your own programming model-you only needWeb. configFile to complete the relevant work-however, we strongly recommend that you refactor your application to avoid storing valuable information in the session state. At the same time, shortening the session lifetime to 20 minutes by default helps protect the security of your users and sites.

About the author

Dino Esposito is a wintellect lecturer and consultant who lives in Italy. He is programming Microsoft ASP. net and the updated introducing Microsoft ASP. net. 0 (both published by Microsoft press). He spent most of his time teaching about ASP. net and ADO. net Courses and presentations at meetings. Browse Dino's Web diary in the http://weblogs.asp.net/despos.