Session Hijacking - How Attackers Steal Logins

About 2 min read

Session hijacking is an attack in which an attacker steals a user's session ID and impersonates that user to access a service. A session ID is an identifier issued by the server after login, and if it is stolen, the service can be used in an authenticated state without even knowing the password. OWASP research lists improper session management as one of the major vulnerabilities in web applications.

Not Carrying an Identifier Across the Moment Privileges Change

In many implementations an identifier is assigned to a visitor before any login takes place, so that display settings or partially entered input can be kept across requests. If the same value continues to be used after authentication, only the state that the value points to changes; the value itself does not. Anyone who managed to learn that value beforehand therefore holds, the moment the legitimate user finishes logging in, a value that now refers to a state carrying the privileges of that user. Whether such a value can be learned in advance is not a question of attacker skill but of whether the application still allows a value supplied from outside to be adopted as the session. This is a different problem from replacing the identifier at fixed intervals. Rotating on a timer shortens how long any single value stays exposed, but it does nothing about a value being carried across the point at which privileges change. What acts on that point is issuing a new value immediately after any operation that changes privileges, and invalidating the old one at the same time. The check is equally simple: compare the value before and after authentication. It is the kind of omission that ordinary functional testing does not surface, because login succeeds either way. A frequent oversight is issuing the new value while leaving the old one valid, so that two identifiers point at the same state and the switch loses its effect.

The Session Theft Flow

Attack Techniques

These include stealing the session ID from cookies using XSS (cross-site scripting), intercepting network communication to steal the session ID, and session fixation attacks that force the use of a session ID prepared in advance.

Concrete Damage Scenarios

A common misconception is that "logging out makes you safe." In reality, a logout process that does not invalidate the session on the server side may leave a stolen session ID still valid. For example, if you log in to online banking over a cafe's public Wi-Fi and your session ID is intercepted through a man-in-the-middle attack, the attacker can use that session to check balances or perform transfers. "Cookie theft," in which malware extracts cookies stored in the browser so that the attacker can access the account in a logged-in state from another device, is also on the rise.

Countermeasures

The basic countermeasures are using HTTPS, setting the Secure and HttpOnly attributes on cookies, and periodically regenerating the session ID. If you set a unique, strong password for each service and enable two-factor authentication, additional authentication will be required for important operations even if a session is hijacked, which mitigates the damage.