Ethical Hacking Session Hijacking
Websites remember who you are through sessions. Session hijacking happens when an attacker steals or guesses that session identity and acts as the user without a password. Ethical hackers test for this weakness so that developers can protect user accounts.
How Sessions Work
The web forgets each request as soon as it finishes. A login page solves the problem by handing the browser a session ID, a long random string stored in a cookie. The browser shows the ID with every later request, and the server recognizes the user.
[Browser] --- username + password ---> [Server]
[Browser] <--- Session ID: A93F7... --- [Server]
[Browser] --- Session ID: A93F7... ---> [Server]
"Welcome back, Maya"
Think of a coat check ticket. Anyone who holds the ticket collects the coat, no questions asked. A stolen session ID works the same way.
Ways Attackers Obtain Session IDs
Sniffing
Sites without HTTPS send cookies in readable form. Anyone on the same network can capture them.
Cross-Site Scripting
A flaw in a web page lets malicious code read cookies and send them out. Developers fix this with the HttpOnly cookie flag.
Predictable IDs
Weak systems create session IDs from simple patterns, such as counting numbers. An attacker guesses the next ID.
Session Fixation
The attacker gives a victim a known session ID before login. After the victim logs in, the attacker uses the same ID.
Malware on the Device
Harmful software on the user's computer can read browser cookies directly.
The Attack Flow
[User logs in] --> [Session ID created]
|
[ID stolen by attacker]
|
v
[Attacker sends ID to server]
|
v
[Server treats attacker as user]
How Testers Check for Weakness
A tester logs in on a lab application and inspects the cookie in the browser's developer tools. Testers look for several problems.
- Cookies missing the Secure flag, which allows transmission over plain HTTP.
- Cookies missing the HttpOnly flag, which lets scripts read them.
- Session IDs that look short, patterned, or predictable.
- Sessions that stay valid after logout.
- Sessions that never expire after long inactivity.
- IDs that stay the same before and after login.
Tools such as Burp Suite help testers collect many IDs and measure how random they are.
Cookie Safety Flags
| Flag | Protection |
|---|---|
| Secure | Sends the cookie only over HTTPS |
| HttpOnly | Blocks scripts from reading the cookie |
| SameSite | Limits sending cookies from other websites |
Defense Checklist for Developers
- Use HTTPS on every page, not only the login page.
- Generate long, random session IDs with a trusted library.
- Create a new ID right after login.
- Destroy the session on the server at logout.
- Set short timeouts for sensitive applications.
- Bind sessions to extra checks, and ask for a password again before risky actions.
Tips for Everyday Users
Log out on shared computers. Avoid public Wi-Fi for sensitive accounts. Keep browsers updated, and turn on two-factor authentication so a stolen session does not give full control.
Legal Reminder
Taking over another person's session breaks computer misuse laws. Practice on intentionally vulnerable lab applications such as DVWA or on your own test sites.
Example Test Report Line
Finding : Session remains valid after logout Risk : Medium Proof : Old cookie reused after logout, page loaded Fix : Destroy the session on the server at logout
Short, clear findings like this one help developers act without confusion.