Advantages and disadvantages of cookieless session in ASP. NET

Advantages of cookieless sessions

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?

Disadvantages of cookieless sessions

Let's examine security from another perspective. Have you ever heard of session hijacking? If not, read The TechNet Magazine article 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:

Connect to a Web site that uses a cookieless session, such as MapPoint, and obtain a ing. The address is stored in the session state.

◆ Capture URL until page name ). Do not include query strings, but make sure that the URL contains session IDs.

◆ Save the URL to a file and copy/send it to another computer.

◆ Open the file on the second computer and paste the URL to the new browser instance.

◆ The same ing is displayed as long as the session times out.

◆ Session IDs can be stolen more easily than ever through cookieless sessions.

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, see Wicked 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 ApplyAppPathModifier method in the HttpResponse class by using the following tips:

 
 

  
  
< a runat="server" href=< % =Response.ApplyAppPathModifier("/test/page.aspx")%> >Click< /a>   
 
 

The ApplyAppPathModifier method uses a URL string as a parameter and returns an absolute URL embedded with session information. 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.

1. Implementation of cookieless sessions
2. ASP. NET Cookie: No problem
3. XML in the. NET Framework: internal principle of XmlSerializer
4. XML base class in the. NET Framework: xsd.exe
5. ASP. NET 2.0 Page Status Persistence: ViewState and Control