ASP Session ID Encryption and Session Security

Once an ASP session begins, a browser request is identified only by its session ID cookie. Any HTTP request with a matching cookie is assumed to have come from the same browser that originated the session. This simple session management approach could open a potential security problem. If a hacker were able to capture, or guess, the session ID cookie in-use by an active session, he or she could submit valid HTTP requests that included this cookie. In this manner, a hacker could hijack, or steal, a user's active session. For example, if a user had supplied valid credit card information, and an ASP script stored this information in the Session object, a hacker who managed to hijack the session could make purchases using the stolen session. If an application requires strong security, a number of solutions can be employed.

Secure Sockets Layer Encryption

Encrypting all communications between the browser and the server prevents hackers from capturing the session cookie. Using Secure Sockets Layer (SSL) encryption, all traffic—including the session cookies—are encrypted, so a hacker sniffing or monitoring the network will not be able to see the private cookies in use. When using SSL encryption, remember that all browser requests to the Web application directory will include the session ID cookie. Even requests for static HTML content in the same application root will include the session ID cookie. All requests to the virtual directory, not just for .asp files, must be encrypted.

Hard-to-Guess Cookie Values

Using encryption prevents hackers from capturing valid cookies. However, a hacker could conceivably guess an active Session ID. ASP Session ID values are selected from a huge range, and are then encrypted. This makes it hard to guess an active cookie. You can obtain higher security by implementing cookies longer than 16 characters and matching them with session variables. Also, keep in mind that if someone does manage to guess a valid cookie once, this will not help him or her guess another valid cookie.

The following precautions are taken when generating ASP session cookies:

• Session ID values are 32-bit long integers.
• Each time the Web server is restarted, a random Session ID starting value is selected.
• For each ASP session that is created, this Session ID value is incremented.
• The 32-bit Session ID is mixed with random data and encrypted to generate a 16-character cookie string. Later, when a cookie is received, the Session ID can be restored from the 16-character cookie string (ASPSESSIONID).
• The encryption key used is randomly selected each time the Web server is restarted.

If the combination of SSL encryption and the complexity of the ASP cookie generation algorithm do not meet your security requirements, user authentication and client certificates can be used in conjunction with session management to provide secure Web applications with client authentication.

For more information about ASP session IDs, and how to design ASP session-aware Web farms, see Managing Sessions in the Active Server Pages documentation.