Forged Cookies

In short: Faked or manipulated session cookies with which an attacker tries to pose as another, already logged-in user.

In more detail: If a session cookie can be guessed, stolen (e.g. via XSS) or simply recreated because of a weak/missing signature method, an attacker can set it in their own browser and is recognised by the server as the original user. Protection: cryptographically signed, random session tokens, HttpOnly/Secure flags on cookies and short session lifetimes.

In Depth

Cookies can be forged or stolen in several ways:

Theft via XSS             - a malicious script reads document.cookie and sends
                             the value to an attacker's server
Session fixation          - the attacker forces a known session ID on the victim
                             before they log in, and takes it over afterwards
Predictable session IDs   - session values follow a guessable pattern
                             (e.g. incrementing numbers instead of real random values)
Man-in-the-middle         - the cookie is read in transit over unencrypted HTTP

The most effective single measure against this is the HttpOnly flag: without this flag, ANY JavaScript injected via XSS can read the cookie value directly — with HttpOnly, the cookie stays completely invisible to JavaScript, even if XSS succeeds. The Secure flag additionally prevents the cookie from being transmitted unencrypted over the network at all.

On the server side, best practice is to generate session IDs in a cryptographically random (unpredictable) way, to regenerate them after a successful login (prevents session fixation) and to set a sensible, not too long expiry time — the shorter the window in which a stolen cookie stays valid, the smaller the possible damage.

Signed cookies as an additional layer of protection

A further line of defence is cryptographically signed cookies: instead of using a raw, meaningless string as the session ID, the server signs the cookie content with a secret key known only to itself (HMAC). If an attacker changes even a single character of the cookie value, the signature no longer matches at the next server check and the cookie is rejected as invalid immediately — so an attacker can’t simply manipulate a user ID in the cookie (e.g. from “user_id=42” to “user_id=1” to pose as a different user) without knowing the secret signing key.

Session hijacking via network eavesdropping

Besides the methods already mentioned, pure network eavesdropping (sniffing) in insecure environments is also a real risk: on an unsecured public Wi-Fi network, anyone on the same network can use a tool such as Wireshark to read unencrypted HTTP traffic and extract session cookies contained in it — made famous by the browser add-on “Firesheep” (2010), which drastically simplified exactly this attack on public networks and demonstrated on a massive scale how many websites at the time transmitted session cookies unencrypted. The Secure flag together with HTTPS throughout makes this particular attack vector practically ineffective today.

Detecting unusual session use

As an additional layer of defence, some applications monitor session usage patterns for anomalies: if a session suddenly changes its IP address or geographical location within a short time (e.g. a login from Germany, and minutes later the same session cookie from another continent), this can indicate a stolen cookie currently being used by an attacker — such systems can automatically invalidate the session or require re-authentication instead of simply allowing the suspicious access.

See also: Cookies, Session