ASP.NET 1.1 Security Guidelines - Session Management

From Guidance Share

Revision as of 05:10, 6 March 2007; Admin (Talk | contribs)
(diff) ←Older revision | Current revision | Newer revision→ (diff)
Jump to: navigation, search

- J.D. Meier, Alex Mackman, Michael Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan


Require authentication for sensitive pages

Make sure that you authenticate users before allowing them access to the sensitive and restricted parts of your site. If you use secure authentication and protect the authentication token with SSL, then a user's session is secure because an attacker cannot hijack and replay a session token. The attacker would need the authentication token to get past the authorization gates.


Do not rely on client-side state management options

Avoid using any of the client-side state management options, such as view state, cookies, query strings, or hidden form fields, to store sensitive data. The information can be tampered with or seen in clear text. Use server-side state management options, for example, a database, to store sensitive data.


Do not mix session tokens and authentication tokens

Secure session management requires that you do not mix the two types of tokens. First, secure the authentication token to make sure an attacker cannot capture it and use it to gain access to the restricted areas of your application. Second, build your application in such a way that the session token alone cannot be used to gain access to sensitive pages or data. The session token should be used only for personalization purposes or to maintain the user state across multiple HTTP requests. Without authentication, do not maintain sensitive items of the user state.


Use SSL effectively

If your site has secure areas and public access areas, you must protect the secure authenticated areas with SSL. When a user moves back and forth between secure and public areas, the ASP.NET-generated session cookie (or URL if you have enabled cookie-less session state) moves with them in plaintext, but the authentication cookie is never passed over unencrypted HTTP connections as long as the Secure cookie property is set.

Note You can set the Secure property for a Forms authentication cookie by setting requireSSL="true" on the <forms> element.

An attacker is able to obtain a session cookie passed over an unencrypted HTTP session, but if you have designed your site correctly and place restricted pages and resources in a separate and secure directory, the attacker can use it to access only to the non-secure, public access pages. In this event, there is no security threat because these pages do not perform sensitive operations. Once the attacker tries to replay the session token to a secured page, because there is no authentication token, the attacker is redirected to the application's login page.


Secure the session data

If the session data on the server contains sensitive items, the data and the store needs to be secured. ASP.NET supports several session state modes. For information about how to secure ASP.NET session state, see "Session State" in Chapter 19, "Securing Your ASP.NET Application and Web Services" at


Personal tools