Introduction

Session hijacking is one of the most practical and misunderstood web attacks. It does not rely on breaking passwords, exploiting cryptography, or abusing server-side vulnerabilities. Instead, it targets the trust relationship established after a user successfully authenticates.

In modern web applications, authentication is not continuous. Once a user logs in, the server issues a session identifier and relies on that value to recognize the user on subsequent requests. If this identifier is exposed, the attacker does not need credentials. The session itself becomes the identity.

How Sessions Actually Work

When a user logs in to a web application, the server validates the credentials and creates a session object on the backend. This session is associated with a unique identifier, commonly stored in a browser cookie.

Example: Set-Cookie: PHPSESSID=9f8a7c2e3b1

From this point forward, every HTTP request sent by the browser includes this cookie. The server does not recheck the username or password. It simply verifies whether the session ID is valid and active.

In practical terms, this means:

• Possession of the session ID equals authenticated access

• The session cookie is more valuable than the password itself

Attack Surface: Where Session Hijacking Begins

Session hijacking becomes possible when session identifiers are exposed through insecure channels. Common attack vectors include:

• Unencrypted HTTP traffic

• Man-in-the-Middle attacks on local networks

• Cross-Site Scripting vulnerabilities

• Insecure Wi-Fi networks

• Malicious browser extensions

In this lab, session hijacking was demonstrated by intercepting HTTP traffic during an active session and extracting the session cookie from the request headers.

Practical Demonstration: Session Hijacking (Lab Environment)

Lab Environment

• Attacker Machine: Kali Linux

• Victim Application: DVWA (Damn Vulnerable Web Application)

• Network: Host-Only Adapter (same subnet)

• Protocol: HTTP (intentionally insecure for demonstration)

Step 1: Identify Network and Victim

First, confirm both machines are on the same network.

On Kali: ip a

On the victim machine: ifconfig

Both machines should have IPs in the same subnet

Discover the victim: netdiscover -r 192.168.56.0/24

This reveals:

• Victim IP

• Router IP

• MAC addresses

This step establishes visibility, which is required for traffic interception.

Step 2: Enable IP Forwarding on Attacker

To remain transparent and avoid breaking connectivity:

echo 1 > /proc/sys/net/ipv4/ip_forward

verify: cat /proc/sys/net/ipv4/ip_forward

If this is not enabled, the victim will lose internet access, exposing the attack.

Step 3: Perform Man-in-the-Middle (ARP Poisoning)

To intercept traffic, the attacker poisons ARP tables of both victim and router.

Terminal 1: arpspoof -i eth0 -t <VICTIM_IP> <ROUTER_IP>

Terminal 2: arpspoof -i eth0 -t <ROUTER_IP> <VICTIM_IP>

At this point:

• Victim believes attacker is the router

• Router believes attacker is the victim

• Attacker sits silently in the middle

Step 4: Capture Session Cookie

Launch Wireshark on Kali:

wireshark

http.cookie

Now, on the victim machine:

1. Open DVWA in browser

2. Log in normally

In Wireshark, observe HTTP requests containing:

Cookie: PHPSESSID=xxxxxxxx

This value is the session identifier used by the server to authenticate the user.

Step 5: Hijack the Session

On the attacker’s browser:

1. Open DVWA

2. Open Developer Tools → Storage → Cookies

3. Replace existing PHPSESSID with the stolen value

4. Refresh the page

The application loads as the authenticated victim
No login required
No credentials used

The server accepts the request purely based on possession of the session cookie.

Step 6: Defense Validation Test

To validate proper defense, the victim logs out.

Now, the attacker refreshes the page using the same cookie.

• If access still works → session invalidation is broken

• If access fails → logout invalidation is correctly implemented

This simple test reveals real-world session handling quality.

Cleanup (Important)

Restore system state after testing:

iptables --flush echo 0 > /proc/sys/net/ipv4/ip_forward

Leaving forwarding enabled is sloppy and dangerous.

Practical Takeaway

This lab demonstrates that session hijacking:

• Does not require password cracking

• Exploits trust, not vulnerabilities

• Is silent and difficult to detect without monitoring

From an attacker’s perspective, stealing a session is often more efficient than attacking authentication mechanisms directly.

From a defender’s perspective, protecting session integrity is as critical as protecting credentials.

Conclusion

This practical exercise demonstrated how session hijacking exploits the way web applications manage authenticated state rather than weaknesses in authentication itself. By intercepting and replaying a valid session identifier, it was possible to assume a user’s identity without knowing their credentials or interacting with the login mechanism.

The lab highlighted an important reality of modern web security: once authentication succeeds, the session becomes the primary trust anchor. If that trust is exposed through insecure transport, poor session handling, or inadequate monitoring, attackers can bypass traditional security controls silently.

From a defensive perspective, this reinforces the importance of enforcing HTTPS, securing cookie attributes, regenerating session identifiers, and properly invalidating sessions on logout. These controls do not prevent sessions from existing, but they significantly reduce the risk of session abuse and limit its impact.