WiFi Attack
Session Hijacking: WiFi Attacks
Technical documentation on Session Hijacking. Understand the attack technique and learn how to defend against...
Medium Threat
Intermediate
When you log into a website, the server creates a session — a temporary record of your authenticated state. The server sends your browser a unique session identifier (a long random string stored as a cookie). On every subsequent request, your browser sends this cookie, and the server looks up the session to know it's you.
Set-Cookie: session_id=eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjoxMjM0fQ [This string is a base64-encoded JSON Web Token (JWT) — contains user ID] [Server decodes it, verifies signature, serves your data]
The security of this scheme depends on the session cookie being secret. If an attacker gets your session cookie, they can send requests to the server with your identity. The server has no way to distinguish the attacker from you — because the cookie is the identity.
Session Hijacking Flow:
[Victim Browser] ──── Cookie: session_id=ABC123 ────→ [Web Server]
[Attacker Browser] ──── Cookie: session_id=ABC123 ────→ [Web Server]
↑
Both appear identical to the server
How Session Cookies Get Stolen Over WiFi
Method 1: Unencrypted HTTP (Simplest)
If the victim visits any HTTP page while logged in, the cookie is sent in plain text across the network. Any attacker on the same WiFi can read it with tcpdump.
$ sudo tcpdump -i wlan1 -A 'tcp[((tcp[12:1] & 0xf0) >> 2):2] = 0xaced' [Capturing HTTP traffic with cookie pattern] POST /api/auth/login HTTP/1.1 Cookie: session_id=eyJhbGciOiJIUzI1NiJ9... email=john%40acmecorp.com
Method 2: Man-in-the-Middle (HTTPS Traffic)
If the victim is on HTTPS but the attacker performs a sufficiently convincing MITM (SSL stripping + certificate substitution, or compromising a trusted CA), the attacker can extract cookies from the decrypted traffic in real time using bettercap or Burp Suite.
Method 3: Stored XSS + Cookie Exfiltration
If the attacker has achieved MITM position, they can inject JavaScript into HTTP pages that reads the victim's cookies (if the cookie has no HttpOnly flag) and sends them to the attacker.
# bettercap session cookie extraction $ sudo bettercap -eval "set http.proxy.script /etc/bettercap/cookies.lua; http.proxy on" # cookies.lua script captures session cookies if string.contains(HTTP.Path, "login") then local session = HTTP.Cookies["session_id"] if session ~= nil then print("COOKIE CAPTURED: " .. session) end end
Real Scenario: Facebook Session at a Coffee Shop
Priya, a journalist, is at a coffee shop in Nairobi working on a sensitive story. She's logged into her Facebook account and browsing while connected to the coffee shop's open WiFi. She only visits HTTPS pages — she's security-conscious.
However, the coffee shop's router has been compromised by an attacker running bettercap. Priya's traffic is being proxied. The attacker extracts her Facebook session cookie from the HTTPS traffic.
The Attack on Priya's Facebook Session:
12:34 - Priya connects to coffee shop WiFi
12:35 - Attacker runs bettercap on the compromised router
12:36 - Priya opens Facebook (HTTPS) — her session cookie is captured
Cookie: c_user=1000123456789; xs=35-abc...; datr=xyz...
12:37 - Attacker imports the cookie into their browser
12:37 - Attacker is now logged into Priya's Facebook as Priya
12:38 - Attacker browses Priya's messages, photos, friend lists
[Priya is still browsing — her session is also still active]
12:45 - Attacker downloads Priya's message history (including sources)
12:52 - Attacker logs out — Priya never knows
Cost to attacker: $0 (used the coffee shop's own compromised router)
Priya's password was never compromised. The session cookie was enough.
The Scary Part
Priya's password was never stolen. She used HTTPS. She did everything right. But she was on a compromised network where the attacker had visibility into all TLS-encrypted traffic (by MITM-ing at the router level using a fraudulently issued certificate). This is why corporate VPNs and endpoint security matter — they protect you even when the network itself is hostile.
Cookie Injection Demonstration
# In Firefox/Chrome DevTools (Attacker side): # After capturing: c_user=1000123456789; xs=35-abc... # Using curl to inject the cookie (command-line): $ curl -b "c_user=1000123456789; xs=35-abc..." \ https://www.facebook.com/profile.php [Returns Priya's Facebook profile page HTML] # Or using browser's DevTools Console: # document.cookie = "c_user=1000123456789; xs=35-abc..."; [Browser now has Priya's session — refresh page to access her account]
Defense Against Session Hijacking
- Use HTTPS for all sites: Prevents passive cookie theft on uncompromised networks
- Use a VPN on public WiFi: Encrypts all traffic, preventing MITM attacks on HTTPS
- Use secure and HttpOnly cookies: The
Secureflag prevents cookies over HTTP;HttpOnlyprevents JavaScript from reading them (mitigates XSS-based cookie theft) - Short session timeouts: Banks and sensitive apps should have short idle timeouts, requiring re-authentication
- Session binding: Bind sessions to IP address or User-Agent string — a session stolen from a different IP/UA is less useful
- Logout on all devices: Many services let you view and revoke active sessions — do this after using public WiFi
- 2FA / MFA: Even with a stolen session cookie, 2FA blocks unauthorized access to sensitive accounts
Understand the Threat. Build the Defense.
Learn how to protect yourself and your organization against Session Hijacking attacks.