21.03.2013 Views

Problem - Kevin Tafuro

Problem - Kevin Tafuro

Problem - Kevin Tafuro

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

9.9 Performing Session ID Management<br />

<strong>Problem</strong><br />

Your web application requires users to log in before they can perform meaningful<br />

transactions with the application. Once the user is logged in, you need to track the<br />

session until the user logs out.<br />

Solution<br />

The solution to this problem is actually straightforward. If the user presents the<br />

proper password, you generate a session ID and return it to the client in a cookie.<br />

While the session is active, the client sends the session ID back to the server; the<br />

server verifies it against an internal table of sessions that has the relevant user information<br />

associated with each session ID, allowing the server to proceed without<br />

requiring the client to continually send the user name and password to the server.<br />

For maximum security, all communications should be done over an SSL-enabled<br />

connection.<br />

The only trick is that the ID should be large and cryptographically random, in order<br />

to prevent hijacking attempts.<br />

Discussion<br />

Unfortunately, there is little that can be done to prevent session hijacking if an<br />

attacker can somehow gain access to the session ID that you need to generate for the<br />

user if the login attempt is successful. Normally, the cookie used to carry the session<br />

ID should not be permanent (i.e., it expires when the user shuts down the browser),<br />

so most browsers will never store the cookie on disk, keeping the cookie only in<br />

memory. While this does not make it impossible for an attacker to obtain the session<br />

ID, it makes it considerably more difficult.<br />

This issue underscores the need to use SSLproperly, which is usually not a problem<br />

between browsers and web servers. Take heed of this for other applications of SSL,<br />

however. If certificates are not properly verified, allowing an attacker to execute a<br />

man-in-the-middle attack, the session ID can be captured. At that point, it hardly<br />

matters, though. If such an attack can be mounted, the attacker can do far worse<br />

than simply capture session IDs.<br />

The only real requirement for generating a session ID is that it should be unique and<br />

not predictable. A base64-encoded 128-bit cryptographically strong random number<br />

should generally suffice for the task, but there are many other ways to achieve the<br />

same end. For example, you could hash a random number or encrypt some identifying<br />

data using a symmetric cipher. However you want to do it is fine—just make sure<br />

486 | Chapter 9: Networking<br />

This is the Title of the Book, eMatter Edition<br />

Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!