What is a Session?
A session allows storing information about a user across multiple HTTP requests. Think of it as a container that holds data such as authentication info, form validation errors, and user preferences. Each session is tied to one user account, but a single user can have multiple sessions from different devices.
In most applications, sessions are stored server-side, but there’s also the concept of stateless sessions, where data is stored client-side (in the user’s browser) using methods like JSON Web Tokens (JWTs). However, since client-side sessions rely entirely on the browser, there must be safeguards to prevent tampering.
What is a Session ID?
Every session is identified by a session ID, a unique, randomly generated string. This ID is what links a user’s HTTP request to their session data on the server.
What is a Session Cookie?
HTTP is stateless, meaning each request is independent. A session cookie allows the server to “remember” the session ID and maintain the user’s session across different HTTP requests. This cookie stores the session ID and is passed back and forth between the server and client.
PHP Sessions
PHP offers built-in session management that uses session IDs stored in cookies and session data stored in the file system. Though PHP sessions are not commonly used by WordPress Core, some plugins may still rely on them.
Authentication Cookies
In WordPress, session cookies are more commonly referred to as authentication cookies (auth cookies). They store more than just the session ID, allowing the user to remain logged in without re-authenticating on every request.
Exploring WordPress’s Session Management
WordPress has a somewhat complex and hybrid approach to session management. Unlike traditional systems that either use only client-side cookies or only server-side sessions, WordPress combines elements of both.
Session Creation
The main function involved in session creation is wp_set_auth_cookie. When a user logs in, WordPress generates both a session token and an authentication cookie.
function wp_set_auth_cookie($user_id, $remember = false, $secure = '', $token = '') {
// ...
$auth_cookie = wp_generate_auth_cookie($user_id, $expiration, $scheme, $token);
$logged_in_cookie = wp_generate_auth_cookie($user_id, $expiration, 'logged_in', $token);
// Send the cookies to the user via setcookie()
}
Here’s a breakdown of how session creation works:
- Session Expiration: WordPress sessions have a fixed expiration date. By default, it’s set to 2 days, or 14 days if the user checks the “remember me” box.
if ($remember) {
$expiration = time() + apply_filters('auth_cookie_expiration', 14 * DAY_IN_SECONDS, $user_id, $remember);
}
This expiration is customizable via the auth_cookie_expiration filter.
Session ID Creation: After validating the user’s credentials, WordPress creates a session ID (or token) and stores it server-side in the database. This is done via the WP_Session_Tokens::create() method, which generates a 43-character random string.
$token = wp_generate_password(43, false, false);
Authentication Cookie: After creating the session ID, WordPress generates an authentication cookie. This cookie is signed with a cryptographic signature to ensure it hasn’t been tampered with.
$auth_cookie = wp_generate_auth_cookie($user_id, $expiration, $scheme, $token);
Why Combine Cookies and Server-Side Sessions?
Before WordPress 4.0, authentication relied solely on cryptographically signed cookies, which presented security challenges, especially for logging users out of other devices or sessions. With the introduction of server-side sessions, WordPress now stores session data in the database (in the user_meta table), improving both security and functionality.
Security & Threat Model
Understanding how WordPress manages sessions is crucial for assessing its security model. Let’s review some common threats and clarify misconceptions.
No Threat: XSS
Contrary to popular belief, XSS attacks cannot easily steal authentication cookies, as they are signed with a cryptographic hash. Even if an attacker intercepts an auth cookie, they wouldn’t be able to forge or modify it.
No Threat: Session Fixation
WordPress’s implementation of session tokens prevents session fixation attacks, where an attacker could trick a user into using a pre-set session ID.
Threat: Man-in-the-Middle (MITM) Attacks
A significant threat remains if the user’s connection isn’t protected by SSL (HTTPS). MITM attackers could intercept authentication cookies. However, using HTTPS mitigates this threat.
Threat: Malware
The most significant risk comes from malware on users’ devices. If malware captures a user’s session cookies, it could potentially allow unauthorized access to their account. Two-factor authentication (2FA) can help mitigate this risk.
Thank you for reading…
by ~Leaveitblank (Mayank Tripathi)