Session Cookie.

What is a session cookie?

A session cookie is a small piece of data that a website stores in your browser so it can recognize you after you sign in. It usually holds a session identifier, also called a session ID or session token. OWASP says a session token is normally a string of variable width. It can be carried in the URL or in the header of the HTTP request as a cookie.

How does a session cookie work?

When you sign in, the website starts a session and gives your browser an identifier. Your browser sends it back with each later request, so the site knows the requests belong to the same session. The OWASP Session Management Cheat Sheet calls cookies the most extensively used mechanism for exchanging session IDs. It says cookies offer security features that other methods, such as URL parameters, do not. It also says the session ID value must be meaningless, so that it does not disclose information.

What is session hijacking or cookie theft?

OWASP describes session hijacking as the exploitation of the web session control mechanism, which is normally managed with a session token. If an attacker gets a valid token, they can use it to gain unauthorized access. When the token sits in a cookie, stealing it is often called cookie theft, and OWASP’s XSS example shows script code reading cookie values.

How do attackers get hold of a session token?

OWASP lists several ways a session can be compromised:

• A predictable session token that can be guessed.
• Session sniffing, which means capturing network traffic to read the token.
• Client-side attacks, such as cross-site scripting (XSS), malicious JavaScript code and Trojans.
• Man-in-the-middle attacks, where the attacker sits between the user and the site.
• Man-in-the-browser attacks.

OWASP gives two examples. In one, attackers use a sniffer to capture a valid session ID and then use that token to gain unauthorized access. In the other, an attacker uses an XSS attack to steal the session token.

What does it look like in simple terms?

This is a simple illustration. A person signs in to a web application. An attacker obtains the session cookie that the browser holds. The attacker presents that cookie to the site, and the site treats the request as coming from the signed-in person.

How can websites reduce the risk?

The OWASP Session Management Cheat Sheet gives these points:

• Session identifiers must have at least 64 bits of entropy, to prevent brute-force session guessing.
• The Secure attribute tells browsers to send the cookie only over an encrypted HTTPS connection.
• The HttpOnly attribute tells browsers not to let scripts access the cookie.
• Session cookies must explicitly set SameSite=Strict (preferred) or SameSite=Lax.
• The session ID must be renewed or regenerated after any privilege level change.
• Applications should use idle and absolute timeouts, and provide a visible and easily accessible logout button.

Is a session cookie the same as a session ID?

Not quite. The session ID is the value that identifies the session. The cookie is one way to carry that value between browser and site. OWASP notes the token can also appear in the URL.

Is session hijacking the same as account takeover?

They are related. Session hijacking targets the session token rather than the password. Account takeover is the wider term for someone gaining control of another person’s account. See also credential theft and multi-factor authentication.

A session cookie can be intercepted by an attacker positioned between the user and the site, as MITRE describes for a man in the middle attack.