Problem - Kevin Tafuro

9.9 Performing Session ID Management
Problem
Your web application requires users to log in before they can perform meaningful
transactions with the application. Once the user is logged in, you need to track the
session until the user logs out.
Solution
The solution to this problem is actually straightforward. If the user presents the
proper password, you generate a session ID and return it to the client in a cookie.
While the session is active, the client sends the session ID back to the server; the
server verifies it against an internal table of sessions that has the relevant user information
associated with each session ID, allowing the server to proceed without
requiring the client to continually send the user name and password to the server.
For maximum security, all communications should be done over an SSL-enabled
connection.
The only trick is that the ID should be large and cryptographically random, in order
to prevent hijacking attempts.
Discussion
Unfortunately, there is little that can be done to prevent session hijacking if an
attacker can somehow gain access to the session ID that you need to generate for the
user if the login attempt is successful. Normally, the cookie used to carry the session
ID should not be permanent (i.e., it expires when the user shuts down the browser),
so most browsers will never store the cookie on disk, keeping the cookie only in
memory. While this does not make it impossible for an attacker to obtain the session
ID, it makes it considerably more difficult.
This issue underscores the need to use SSLproperly, which is usually not a problem
between browsers and web servers. Take heed of this for other applications of SSL,
however. If certificates are not properly verified, allowing an attacker to execute a
man-in-the-middle attack, the session ID can be captured. At that point, it hardly
matters, though. If such an attack can be mounted, the attacker can do far worse
than simply capture session IDs.
The only real requirement for generating a session ID is that it should be unique and
not predictable. A base64-encoded 128-bit cryptographically strong random number
should generally suffice for the task, but there are many other ways to achieve the
same end. For example, you could hash a random number or encrypt some identifying
data using a symmetric cipher. However you want to do it is fine—just make sure
486 | Chapter 9: Networking
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.