Session hijacking is the digital equivalent of someone snatching your signed-in badge as you walk through a secure door, then using it to access everything you could. This concept matters for the 312-50 exam because it tests how attackers exploit the trust between a user and a web server without needing a password. You will need to recognise the techniques used to steal session tokens and the controls that prevent these attacks.
Jump to a section
A simple way to picture Session Hijacking
A busy coffee shop on a Saturday morning. You grab a table, connect to the free Wi-Fi, and log into your email. The coffee shop gives you a numbered ticket for your browsing session – ticket 42. Every time you check your email, you show the server your ticket to prove it's you. Someone else at the counter, let's call him Dave, orders a latte and also gets ticket 42 because the barista made a copy by mistake. Dave can now, without knowing your password, access your email by showing the server ticket 42. The server believes Dave is you because the ticket matches. You are locked out, and Dave reads your messages, sends emails in your name, and even orders a dozen cupcakes using your saved payment details. The coffee shop has no idea anything is wrong because ticket 42 is valid. Your session is hijacked. Dave never needed to crack your password – he just stole the valid ticket from the server's side. This is exactly session hijacking in the digital world: an attacker takes over your active, authenticated session by stealing or predicting the session token (the ticket) that the web server uses to keep you logged in.
Session hijacking is a type of attack where an attacker takes over a valid communication session between a user and a server. A session is a temporary, interactive information exchange between two devices – like your laptop and a website – that begins when you authenticate (log in) and ends when you log out or close the browser. DuriLogin, the server creates a unique session identifier (session ID) and sends it to your browser as a small text file called a cookie. This cookie is like a temporary keycard that lets you access your account without having to log in again on every page. The server trusts that anyone presenting that valid session ID is you.
The attacker's goal in session hijacking is to obtain that session ID and use it to impersonate you. There are three main ways they do this: session side-jacking, session fixation, and session prediction. - Session side-jacking (sometimes called session sniffing) happens when an attacker intercepts the session ID as it travels over an unencrypted network. For example, if you log into your bank over a public Wi-Fi network without HTTPS (the secure version of HTTP that encrypts data), anyone on that network using a packet sniffer (a tool that captures network traffic) can see your session ID cookie fly by. They copy that cookie into their own browser and boom – they are now logged into your bank account. - Session fixation is more sneaky. The attacker tricks the victim into using a session ID that the attacker already knows. The attacker might send you a link that looks legit but includes a specific session ID, like http://bank.com?sessionid=hacked123. If you log in using that link, the server associates your authenticated session with the attacker's predefined session ID. The attacker then uses that same ID to access your account. The server never knows the difference because it sees a valid session that was just authenticated. - Session prediction involves the attacker guessing or calculating a valid session ID. Some web servers generate session IDs in predictable patterns, like sequential numbers (e.g., 1001, 1002, 1003) or based on timestamps. An attacker can analyse a few captured IDs, figure out the pattern, and then generate an ID for a session that hasn't started yet – typically one belonging to an administrator or privileged user.
Why does this happen? Because sessions require trust. The server trusts that the person holding the session ID is the same person who authenticated earlier. This trust is a weakness if the session ID is not properly protected. Modern websites use strong encryption (HTTPS), random session ID generation, and short session timeouts to reduce risk, but older web applications or misconfigured systems remain vulnerable.
The impact of session hijacking is severe. An attacker can read private messages, make purchases, change passwords, or steal personal data without ever knowing your username or password. In a corporate environment, hijacking a session belonging to a system administrator could give the attacker full control over company servers.
For the 312-50 exam, you need to understand that session hijacking targets the session layer (layer 5) of the OSI model – a reference framework that defines seven layers of network communication. It exploits the fact that the session ID is the only thing verifying the user's identity after login. Defences include using HTTPS everywhere, regenerating session IDs after login, implementing secure cookies with the HttpOnly and Secure flags, and enforcing session timeouts.
Track a Valid Session
The attacker identifies a target user who is actively logged into a vulnerable web application. The attacker uses a packet sniffer (like Wireshark) or a proxy tool (like Burp Suite) to monitor network traffic and locate the session ID cookie in the HTTP headers. This step is passive – no interaction with the victim yet.
Capture the Session ID
If the traffic is unencrypted (HTTP), the attacker extracts the session ID directly from the captured packet. If the traffic is encrypted (HTTPS), the attacker must use a different method, such as exploiting a cross-site scripting (XSS) vulnerability to steal the cookie via JavaScript, or performing a man-in-the-middle attack on the user's device to downgrade the connection to HTTP.
Desynchronise the Legitimate User
The attacker causes the victim's session to become idle or disconnected. This can be achieved by sending a TCP reset packet (for lower-layer hijacking) or by launching a denial-of-service (DoS) attack that overwhelms the victim's connection. This step ensures the attacker can use the session ID without interference.
Take Over the Session
The attacker injects the captured session ID into their own browser (by modifying a cookie using a tool like Cookie-Editor or by manually editing the HTTP request). They then access the target web application. The server sees the valid session ID and grants the attacker the victim's authenticated access.
Maintain Access and Exploit
Once inside, the attacker performs actions as the victim: reading emails, making purchases, changing account details, or launching further attacks from within the authenticated session. The attacker may also modify the session to prevent the victim from logging back in, effectively locking them out of their own account.
Cover Tracks
The attacker deletes server logs or modifies session records to hide their activity. In modern systems, this is difficult, but the attacker may use proxy servers or VPNs to obscure their IP address, making forensic analysis harder.
An IT professional, for example a security analyst at a mid-sized e-commerce company, uses knowledge of session hijacking to protect the company's web application and investigate suspicious activity. Picture this: the company runs an online store selling custom furniture. Customers log in, browse products, add items to their basket, and check out. The web developer built the site ten years ago and never updated the session handling. Sessions use simple sequential IDs (e.g., 1001, 1002) and cookies are sent over HTTP without encryption (no HTTPS on the entire site).
One day, the analyst receives an alert from the company's web application firewall (WAF). The alert shows that a single IP address from a different country is accessing multiple customer accounts within minutes. The analyst knows this is a classic sign of session prediction or side-jacking. The step-by-step response would be:
First, the analyst checks the server logs to see the session IDs being used. They notice the IDs are sequential: customer A logged in with ID 5005, customer B with ID 5006, and the attacker is using ID 5008 even though customer C logged in five minutes ago with ID 5007. The attacker is predicting the next session ID without authentication.
Second, the analyst uses a packet analyser (like Wireshark) to capture live traffic from the public Wi-Fi the company's mobile customers sometimes use. No encryption means session IDs are visible in plain text. The analyst confirms that session side-jacking is also possible.
Third, the analyst documents the findings and reports to the development team. They recommend immediate changes: enable HTTPS across the entire site, switch from sequential to cryptographically random session IDs (using a strong pseudo-random number generator), set the Secure flag on all cookies so they only transmit over HTTPS, and set the HttpOnly flag to prevent JavaScript from reading the cookie.
Fourth, the analyst implements a session regeneration policy. Every time a user logs in (even if they were already logged in), the server issues a new session ID. This destroys any fixed or predicted session ID the attacker might have prepared.
Fifth, they set a short session timeout (e.g., 15 minutes of inactivity). If the attacker steals a session ID but the user's session expires, the attacker cannot reuse it.
Finally, the analyst monitors for future attacks using the WAF rules that detect unusual session ID patterns (e.g., multiple sessions from the same IP with different IDs within seconds). They also run regular vulnerability scans using tools like OWASP ZAP or Burp Suite to test for session hijacking weaknesses.
This real world scenario shows that session hijacking is not just a theoretical exam topic – it is a daily threat for IT professionals who manage web applications. The analyst's work directly prevents data breaches, financial loss, and damage to the company's reputation.
The 312-50 exam tests session hijacking in a very specific way. The questions are scenario-based, and you must identify the attack type, the best countermeasure, or the step an attacker would take next. The exam loves details that beginners overlook.
First, the exam will present a scenario like 'A user logs into a web application over an unencrypted Wi-Fi network. Later, an attacker gains access to the user's account without knowing the password.' The correct answer is almost always 'session side-jacking' if the description involves capturing network traffic. If the scenario says the attacker sent the victim a link with a specific session ID, the answer is 'session fixation'. If the scenario says the attacker analysed several session IDs and predicted the next one, the answer is 'session prediction'.
Second, the exam tests countermeasures. The most common correct answers include:
Use HTTPS and the Secure flag for cookies.
Regenerate session IDs after login.
Use random, long session IDs (at least 128 bits).
Set short session timeouts.
Use HttpOnly cookies to prevent XSS (cross-site scripting) from stealing the cookie.
Third, the exam loves to test the difference between session hijacking and session replay. Session replay is when an attacker captures a copy of the entire encrypted session (including the session ID) and retransmits it later. Session hijacking is taking over an active, current session. Both involve stealing session data, but the question will give clues about timing.
Fourth, the exam will ask about tools used for session hijacking. Be ready to recognise tools like:
Wireshark (for packet capture)
Burp Suite (for intercepting and modifying HTTP traffic)
OWASP ZAP (open source web app scanner)
Cookie-Editor or similar browser extensions (for modifying cookies manually)
Ferret and Hamster (older tools specifically for session side-jacking)
Common traps in the exam: - 'Session hijacking requires the attacker to know the victim's password.' This is false. The attacker only needs the session ID, not the password. - 'Session hijacking only works on HTTP sites.' The exam will test that HTTPS alone does not prevent session hijacking if the session ID is still sent in cookies that are accessible via JavaScript (no HttpOnly flag) or if the session ID is predictable. - 'A firewall prevents session hijacking.' Firewalls do not inspect the content of HTTP sessions, so they are not effective against this attack.
Memorise the three phases of session hijacking that EC-Council loves: tracking (finding a valid session), desynchronising (forcing the legitimate user to become idle or disconnect), and taking over (the attacker uses the session ID). Also know that session hijacking can target TCP sessions (lower layer) or application layer sessions (HTTP). The exam focuses on application layer (HTTP) session hijacking because it is more common.
Finally, the exam expects you to know that session hijacking is part of the 'Man-in-the-Middle' (MITM) family of attacks. If a question describes an attacker intercepting traffic between two parties without their knowledge, session hijacking is often the next step after the MITM position is established.
Session hijacking allows an attacker to take over a user's active session without knowing their password.
The three main types of session hijacking are session side-jacking (sniffing), session fixation (pre-set ID), and session prediction (guessing the ID).
Session side-jacking occurs when an attacker captures the session ID from unencrypted network traffic, often over public Wi-Fi.
Session fixation tricks the victim into authenticating with a predefined session ID that the attacker knows.
Session prediction involves an attacker analysing the pattern of session ID generation to guess a valid ID.
The most effective countermeasures include using HTTPS with Secure and HttpOnly flags, regenerating session IDs after login, and setting short session timeouts.
Session hijacking exploits the trust between a server and an authenticated client, not the authentication itself.
The 312-50 exam tests your ability to identify the attack type from a scenario and recommend the correct defence.
Common tools used in session hijacking attacks include Wireshark, Burp Suite, and Ferret.
Session hijacking is a form of man-in-the-middle (MITM) attack and targets the application layer of the OSI model.
These come up on the exam all the time. Here's how to tell them apart.
Session Hijacking
Attacker takes over an active, ongoing session immediately.
Requires capturing the session ID while the session is active.
The legitimate user may be locked out or disconnected.
Session Replay
Attacker captures the entire encrypted session and retransmits it later.
Does not require the session to be active at the time of replay.
The legitimate user is usually not affected during the replay.
Session Side-Jacking
Attacker passively sniffs the session ID from network traffic.
No interaction with the victim before the attack.
Works best on unencrypted networks (HTTP).
Session Fixation
Attacker actively tricks the victim into using a predetermined session ID.
Requires sending a phishing link or malicious content to the victim.
Can work on encrypted networks if the victim clicks the link.
Session Hijacking (Application Layer)
Targets the session ID in HTTP cookies or URLs.
Easier to execute – many tools available (Burp Suite, Cookie-Editor).
Countermeasures: secure cookies, HTTPS, session regeneration.
TCP Session Hijacking (Transport Layer)
Targets the TCP sequence numbers to inject packets into a TCP stream.
More difficult – requires predicting sequence numbers and crafting raw packets.
Countermeasures: encryption (IPsec), random sequence numbers.
Session Hijacking
Directly steals the session ID to impersonate the user.
Does not require executing code in the user's browser.
Often relies on network-level access (sniffing).
Cross-Site Scripting (XSS)
Injects malicious scripts into a website that steal cookies when executed in the user's browser.
Requires a vulnerable website that does not sanitise user input.
Often used specifically to steal session cookies.
HTTP Session (Stateless)
Session ID sent in plain text in HTTP headers.
Vulnerable to sniffing on any network.
No built-in integrity check – easy to modify.
HTTPS Session (Encrypted)
Session ID sent encrypted inside SSL/TLS tunnel.
Sniffing alone does not reveal the session ID.
Still vulnerable if the session ID is predictable or stored insecurely.
Mistake
Session hijacking is the same as stealing a password.
Correct
Session hijacking steals the session token (like a temporary key), not the password. The attacker never needs to know or crack the password.
Beginners think 'accessing an account' always requires a password. They don't realise that after login, the session ID acts as the sole authenticator.
Mistake
If a website uses HTTPS, session hijacking is impossible.
Correct
HTTPS encrypts the data in transit, but if the session ID is predictable, or if the session ID is stored in a cookie without the Secure and HttpOnly flags, the attacker can still steal it via malware on the user's device or by predicting it.
People assume encryption solves all security problems. They don't understand that session IDs can be vulnerable on the client side or be predicted even if encrypted.
Mistake
Session hijacking only happens over public Wi-Fi.
Correct
Session hijacking can happen over any network where the attacker can intercept traffic (e.g., through malware on the victim's device, a compromised router, or via session fixation through phishing links).
Beginners often associate the attack with coffee shop Wi-Fi stories. They forget that home networks and corporate networks can also be compromised.
Mistake
A strong password protects against session hijacking.
Correct
A strong password has no effect on session hijacking. Once logged in, the password is irrelevant. The session ID is the only credential used for subsequent requests.
Most people are taught that strong passwords are the ultimate defence. They don't realise that session hijacking bypasses password security entirely.
Mistake
Session fixation is the same as session side-jacking.
Correct
Session fixation tricks the victim into using a session ID the attacker already knows. Session side-jacking intercepts the session ID in transit. They are different attack vectors.
Both involve stealing a session ID, so beginners lump them together. They miss the distinction in how the ID is obtained (active trickery vs passive sniffing).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
No. Websites that use HTTPS, random session IDs, and secure cookie flags (HttpOnly and Secure) are much harder to hijack. However, no website is 100% safe if the user's device is compromised.
A VPN encrypts traffic between your device and the VPN server, but the VPN provider can still see your traffic. If the VPN provider is malicious or if your traffic leaves the VPN to an unencrypted website, hijacking is still possible at that point. The VPN does not protect against session fixation or prediction.
Yes, in most cases session hijacking involves stealing the session cookie that contains the session ID. However, an attacker can also hijack a session by predicting the ID without ever seeing the cookie.
MITM is the positioning of the attacker between two parties to intercept traffic. Session hijacking is one specific action the attacker takes after achieving that position – they steal the session ID and impersonate one party.
Use deliberately vulnerable applications like DVWA (Damn Vulnerable Web Application) or OWASP WebGoat, hosted on your own machine or a private lab. Never test against real websites without explicit written permission.
Logging out destroys the session on the server side, so the session ID becomes invalid. This is a good practice. However, if the attacker steals your session ID while you are still logged in, logging out later will not undo any damage done during the hijacked session.
You've finished Session Hijacking. Continue through the 312-50 study guide to build a complete picture of the exam.
Done with this chapter?