Sessions and Tokens: Why They Exist

This is why the block exists and why every attack in it aims at the token: session hijacking is taking over a session by obtaining its token, and it bypasses the password entirely, along with any strength that password had. A sixteen-character password protects nothing if the token it produced can be stolen.

What a good token must be

Since the token is a credential, it must have the properties a credential needs, and these anticipate the attacks:

• Unpredictable. It must be generated with enough randomness (entropy) that an attacker cannot guess or calculate a valid one. A token derived from a sequence, a timestamp, or a weak random source can be predicted, which is one of the attacks in the next chapter. This connects to the cryptographic-weaknesses chapter: a token is only as unguessable as the randomness that made it.
• Long enough that brute-force guessing is infeasible, for the same reason a password must be long.
• Secret in transit and at rest. It must not be exposed to anyone but the user and the server, which requires HTTPS in transit and care in how the browser stores it.
• Bound to a single session and invalidated when that session ends.
• Limited in lifetime, so a stolen token is useful only briefly.

Each of these is a defence against a specific attack, which is why the next chapters can be read as "here is how a token is stolen or guessed, and here is the property that prevents it".

Where the token lives

The token is usually stored in a cookie, a small piece of data the browser holds for a site and sends automatically with each request to that site. Cookies are convenient for this because the browser handles sending them, and they can carry security attributes (the subject of a later chapter) that control how they are protected.

Tokens can also be held in other browser storage and sent explicitly by the site's script, an arrangement common in modern applications. The trade-offs between the two are a detail the block returns to; for now the point is that the token is stored on the client and sent with requests, and wherever it is stored, protecting it is the goal.

A crucial distinction the block will use: the server keeps the session (the record of who you are and what you are doing), and the client keeps the token (the key that points to that session). The token is not itself the session; it is the key to it. Stealing the key gives access to the session, which is why protecting the key is everything.

A worked example

Asha logs in to her bank. Trace what happens:

1. She sends her username and password once, over HTTPS.
2. The server verifies them, creates a session recording that this session belongs to Asha and is authenticated, generates a long random token, and sends it to her browser in a cookie.
3. Her browser sends that cookie with every subsequent request. Each time, the server looks up the token, finds Asha's session, and serves her account data without asking for the password again.
4. When she logs out, the server invalidates the session, so the token no longer points to anything and is useless.

Now suppose an attacker obtains that token while it is valid. They send it with a request, the server looks it up, finds Asha's authenticated session, and serves them her account data, because the server cannot tell the request did not come from Asha: it carries her valid token. The attacker never knew her password, and her password's strength was irrelevant. That is session hijacking, and the block is about the ways the token can be obtained and the properties and controls that prevent each.

What beginners get wrong

• Thinking hijacking needs the password. It needs the token, which is stolen or guessed without the password ever being involved, so it bypasses the password and its strength entirely.
• Believing a strong password protects the session. It protects the login; once the token is issued, the token is what matters, and it can be stolen independently.
• Confusing the token with the session. The server holds the session; the client holds the token, which is the key to it. Stealing the key gives access to the session.
• Treating the token as less sensitive than the password. It is a credential of equal sensitivity, and it is transmitted with every request, so it is often more exposed.
• Assuming a token is safe because it looks random. It is only unguessable if generated with sufficient entropy from a secure source; a predictable token is a guessable credential.

Quick revision

• HTTP is stateless, so after login a site issues a session token (a long random string) that the browser returns with each request; the server looks it up to know the user is authenticated. Log in once, the token carries the identity.
• The token stands in for the identity: any request with a valid token is treated as that user, without re-checking the password, so possessing the token is as good as knowing the password, for the session's life. This is why hijacking bypasses the password and its strength.
• A good token is unpredictable (enough entropy, from a secure source), long, secret in transit and at rest, bound to one session, and limited in lifetime. Each property prevents a specific attack.
• The token is usually held in a cookie (sent automatically, can carry security attributes) or other browser storage. The server holds the session; the client holds the token, the key to it.

Test yourself

1. Why does a web application need a session token, and what problem does it solve?

Because HTTP is stateless, so each request is independent and the server does not inherently know that a request comes from someone who logged in earlier. Without a token, the user would have to send their password with every request, which is insecure and impractical. The token, issued at login and returned with each subsequent request, lets the user authenticate once and have their identity carried through the visit.

1. Why is possessing a session token as good as knowing the password?

Because the server treats any request carrying a valid token as coming from the authenticated user, without re-checking the password, since avoiding that re-check is the token's purpose. So an attacker who obtains a valid token is treated as that user, with their account, data and privileges, without needing the password, and the password's strength is irrelevant once the token can be stolen.

1. What is the distinction between the session and the token, and why does it matter?

The session is the server's record of who the user is and what they are doing; the token is the value held by the client that points to that session. The token is the key to the session, not the session itself. It matters because stealing the key gives access to the session, so protecting the token is what protects the session.

1. What properties must a good session token have, and which attack does each prevent?

It must be unpredictable, generated with sufficient entropy from a secure source, which prevents guessing or calculating a valid token; long, which prevents brute forcing; secret in transit and at rest, which prevents theft by sniffing or from the browser; bound to a single session and invalidated when it ends; and limited in lifetime, which limits the usefulness of a stolen token.

1. Why does a strong password not protect a user against session hijacking?

Because session hijacking targets the token, not the password: the token is obtained by theft or prediction after login, and the server then treats the attacker as the user on the strength of the token alone. The password secured the initial login, but once the token is issued it is the token that grants access, and it can be stolen independently of how strong the password was.