Because Web applications are built on the stateless HTTP protocol, session management is an application-level responsibility. Examine the approach to session management by your application because it directly affects the overall security of your application. Table 5.6 shows the most common vulnerabilities associated with session management.
Vulnerability | Implications |
---|---|
Passing session identifiers over unencrypted channels | Attackers can capture session identifiers to spoof identity. |
Prolonged session lifetime | This increases the risk of session hijacking and replay attacks. |
Insecure session state stores | Attackers can access the private session data of a user . |
Session identifiers in query strings | Session identifiers can easily be modified at the client to spoof identity and access the application as another user. |
Use the following questions to help validate the handling of sensitive data by your application:
How are session identifiers exchanged?
Do you restrict session lifetime?
How is the session state store secured?
Examine the session identifier that your application uses to manage user sessions and how these session identifiers are exchanged. Consider the following:
Do you pass session identifiers over unencrypted channels?
If you track session state with session identifiers ” for example, tokens contained in cookies ” examine whether or not the identifier or cookie is only passed over an encrypted channel, such as SSL.
Do you encrypt session cookies?
If you use Forms authentication, make sure your application encrypts the authentication cookies using the protection="All" attribute on the <forms> element. This practice is recommended in addition to SSL to mitigate the risk of an XSS attack that manages to steal the authentication cookie of a user.
Do you pass session identifiers in query strings?
Make sure that your application does not pass session identifiers in query strings. These strings can be easily modified at the client, which would allow a user to access the application as another user, access the private data of other users, and potentially elevate privileges.
Examine how long your application considers a session identifier valid. The application should limit this time to mitigate the threat of session hijacking and replay attacks.
Examine how your application stores session state. Session state can be stored in the Web application process, the ASP.NET session state service, or a SQL Server state store. If you use a remote state store, make sure that the link from the Web server to the remote store is encrypted with IPSec or SSL to protect data over the wire.
For more information about securing ASP.NET session state, see "Session State" in Chapter 19, "Securing Your ASP.NET Application and Web Services."