Session Hijacking

Description

The session identifier is obtained in several ways. The most common is theft of the session cookie — by intercepting traffic on an unprotected connection, through a flaw on the site that allows the cookie to be read, or with malware. Identifiers can also be predicted when the service generates them by a weak and foreseeable pattern. The third is session fixation, where the attacker leads the victim to log in on an identifier they already know.

The defense is to stop cookies leaking and to stop them being guessed. An encrypted connection prevents interception, cookie flags hide it from scripts and from being sent in the clear, and regenerating the identifier immediately after login makes fixation pointless. For sensitive actions it is always worth asking for identity to be confirmed again, which you will often see on banking services. Session hijacking is close to token theft — a session cookie is a kind of token; the difference is that the emphasis here is on the web session and its identifier.

Examples

• The attacker intercepts a session cookie on an unprotected wireless network and carries on using the victim's account without logging in once.
• A flaw on a site allows a malicious script to read the session cookie out of the browser and send it to the attacker.
• The attacker sends the victim a malicious link carrying a prepared identifier. The victim logs in, the vulnerable service does not change the identifier after login, and the attacker is left with an active session to walk into as a logged-in user.

Notes

• It is close to token theft — a session cookie is a kind of token; the difference is that hijacking is tied to the web session.
• An encrypted connection and a fresh session identifier immediately after login remove most of the risk.