Network and Perimeter Hacking · Topic 7 of 9
Session Hijacking
Session hijacking explained: application and network level attacks, the tools used, and countermeasures such as HTTPS, secure cookies and ID regeneration.
- 5 min
- Hijacking takes over an existing session. Spoofing creates a new false one.
- Application level targets session IDs. Network level targets TCP or UDP connections.
- Fixation is stopped by regenerating the session ID at login.
What it is
Session hijacking is taking over a valid, authenticated session between a user and a server. The attacker does not need the password because the session already proves who the user is. After taking over, the attacker acts with the victim's rights.
Hijacking differs from spoofing: spoofing starts a new session with a false identity, while hijacking takes over one that already exists.
How it works
Concepts
HTTP is stateless, so a web application sends a session ID (token), usually in a cookie, and the browser returns it with every request. Whoever holds the ID is treated as the user. A hijack follows three broad steps: place yourself in a position to see or guess the session, take over the session (often making the real user drop out), and then use it.
There are two levels. Application level hijacking targets the session ID used by a web application. Network level hijacking targets the transport layer connections such as TCP, and works against many protocols.
Application level attacks
| Attack | Idea |
|---|---|
| Session sniffing | Capturing the ID from cleartext traffic, especially over HTTP or public wireless |
| Predictable session token | Guessing IDs that are sequential or based on a weak algorithm |
| Cross site scripting (XSS) | Script in a page steals the cookie (blocked by HttpOnly cookies) |
| Man in the middle and man in the browser | An on-path attacker or malware in the browser reads the session |
| Session fixation | The attacker sets a known session ID, the victim logs in with it, and the attacker reuses it |
| Cross site request forgery (CSRF) | Makes the victim's browser send a request using the session. It misuses the session rather than stealing it |
| Session replay | Resending a captured token or request |
| Session donation | The attacker gives the victim their own session so the victim's actions land in the attacker's account |
| CRIME and BREACH style attacks | Compression based side channels that leak secrets from encrypted traffic |
| Forbidden attack | Abuse of a repeated nonce in TLS with Galois/Counter Mode (GCM) |
Network level attacks
| Attack | Idea |
|---|---|
| TCP/IP hijacking | Predicting or sniffing sequence numbers and injecting packets into a connection |
| Blind hijacking | Injecting data without seeing the replies |
| Man in the middle | Sitting on the path and relaying or altering the connection |
| RST hijacking | Sending a forged reset packet to end the connection |
| UDP hijacking | Sending forged replies before the real server answers, since UDP has no sequence numbers |
| ICMP and ARP based tricks | Redirecting traffic to place the attacker on the path |
| Source routing | Forcing packets through the attacker's system (largely disabled now) |
When the attacker injects into a TCP connection, the real client and server get out of step because sequence numbers no longer match. This desynchronization causes the legitimate client to lose the session, and "ACK storms" can result.
Tools
| Tool | Use |
|---|---|
| Burp Suite and OWASP ZAP | Intercepting proxies that show and modify cookies and requests |
| Ettercap and Bettercap | On-path attacks and session capture on a local network |
| Wireshark | Captures cleartext tokens |
| Hamster and Ferret (sidejacking) | Captured cookies from unprotected sites. Historic examples |
| Firesheep | Browser extension that made cookie theft on open wireless easy and drove adoption of HTTPS |
Countermeasures
- Use HTTPS everywhere with HSTS, so tokens never cross the network in cleartext.
- Mark cookies Secure (HTTPS only), HttpOnly (not readable by scripts) and use the SameSite attribute against CSRF.
- Generate long, random session IDs, regenerate the ID after login to defeat fixation, and destroy it at logout.
- Set idle and absolute timeouts, and bind sessions to extra context where suitable.
- Use SSH instead of Telnet and IPsec or VPNs for network level protection.
- Use anti CSRF tokens, validate input to stop XSS, and monitor for the same session ID used from two places.
- Avoid putting session IDs in URLs.
A worked example
A user logs in at a coffee shop over a site that uses HTTP after login. An attacker on the same network captures the cookie and opens the account without a password. The correct fix is HTTPS for the whole site with Secure cookies and HSTS, not a stronger password.
How the exam asks about this
- "An attacker sets a known session ID, lets the victim authenticate, then uses it. What attack?" -> Session fixation.
- "Which cookie attribute stops client side script from reading the cookie?" -> HttpOnly.
- "Which protocol feature should replace Telnet to defend against network level hijacking?" -> SSH (encrypted sessions).
What to remember for the exam
- Hijacking takes over an existing session. Spoofing creates a new false one.
- Application level targets session IDs. Network level targets TCP or UDP connections.
- Fixation is stopped by regenerating the session ID at login.
- Secure, HttpOnly and SameSite are the cookie protections to name.
- TCP hijacking involves sequence number prediction and desynchronization.
HttpOnly stops script from reading a cookie but does not stop a network sniffer. Secure and HTTPS deal with sniffing.
Common mistakes
Mixing fixation and prediction. Fixation sets the ID. Prediction guesses it.
Treating CSRF as token theft. CSRF uses the browser's existing session without ever reading it.
Relying on strong passwords. They do not protect a session token already issued.
Check yourself
Why does regenerating the session ID after login matter?
It prevents session fixation because any ID set before login becomes useless.
What does the Secure cookie flag do?
It makes the browser send the cookie only over HTTPS.
What is the effect of an injected TCP segment on the real client?
Sequence numbers fall out of step, so the real client is desynchronized and loses the session.
Topic 7 of 9 in Network and Perimeter Hacking
Test yourself on Network and Perimeter Hacking
The full EC-Council 312-50 question bank has 1,000 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by EC-Council. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.