A vulnerable session ID implementation

When it comes to session management, developers use a session ID to identify a user’s session due to the stateless nature of the http protocol. But in a recent test, we found the application using a session ID for the browser session rather than each user session.

The session ID remains the same for all users logging in from the same browser session. At the server, the application just maps the session ID to each new user. This reduces the overhead for the application as it does not generate a random session ID every time a new user logs in.

But this is vulnerable.

Here’s why: in shared computers, the attacker can steal the session ID by first logging in to the application, peeking at the session ID and then leaving the window open. Then any user logging into the application from the same browser instance gets the same session ID (already known to the attacker) and becomes vulnerable to a session hijacking attack.

Even SSL won’t protect against session hijacking above, as the session ID is stolen from the client itself.

The best practice for session IDs is to generate unique, random, short-lived session IDs for each individual user login; that will prevent the session id from being stolen at the source. Here’s an excellent paper on session management by Gunter Ollmann.

Plynt provides penetration testing and code review services to clients worldwide. If you are interested, please contact us for a quote. We’ll get back to you within one working day.

Add yours.closed for this post.