Title: Session Hijacking Lab: Full Setup

+ Attack (Kali + DVWA)[1]

Overview
Students will set up a two‑VM lab (attacker: Kali; victim: Linux + DVWA), perform
a cookie‑based session hijacking attack over HTTP, optionally capture the cookie
in transit using a proxy, and validate mitigations.[2]

Learning Objectives
• Build an isolated two‑VM lab and verify connectivity.[3]

• Install and configure DVWA for HTTP and low security.[3]

• Hijack a session by reusing the victim’s PHPSESSID cookie.[2]

• Optionally capture PHPSESSID over HTTP using an intercepting proxy.[4]

• Apply and validate mitigations: HTTPS/HSTS, Secure/HttpOnly/SameSite

flags, session ID regeneration, logout invalidation.[5]

Required Software and Materials

• Hypervisor: VirtualBox or VMware.[6]

• Attacker VM: Kali Linux with Firefox and Burp Suite Community.[6]

• Victim VM: Linux (Debian/Ubuntu recommended) with DVWA installed

(Docker or native LAMP).[3]

Network Topology
• Two VMs on the same Host‑only or NAT network; victim reachable at
[Link] from Kali; no Internet needed once set up.[3]

Important Lab Rules

• Perform all actions only inside the course lab network.[2]
 • Do not attack any system not explicitly provided for this lab.[2]

Section 1 — VM Creation and Network

Setup must succeed before proceeding

1. Create two VMs

• Attacker: “Kali” (Firefox, Burp are available).[6]

• Victim: “Victim‑Linux” (Debian/Ubuntu recommended).[6]

2. Attach both VMs to the same Host‑only or NAT network.[6]

3. Find IP and verify connectivity

• On each VM: run ip a (or ifconfig) to find IP.[6]

• From Kali: ping <victim‑ip> must succeed.[6]

Screenshot Deliverables (label exactly as below in captions)

• “Kali IP” (terminal showing ip a).[6]

• “Victim IP” (terminal showing ip a).[6]

• “Connectivity” (successful ping from Kali to victim).[6]

Section 2 — DVWA Installation on Victim

Choose one method (Docker = fastest)

Option A — Docker

• Install Docker:

o sudo apt update && sudo apt install -y [Link] && sudo systemctl
enable --now docker.[6]
 • Run DVWA:

o sudo docker run --rm -it -p 80:80 vulnerables/web-dvwa. Keep this

terminal open.[7]

• Verify from Kali: open [Link] and confirm DVWA login page.[7]

Option B — Native LAMP + DVWA

• Install stack:

o sudo apt update && sudo apt install -y apache2 mariadb-server php php-
mysqli git.[3]

o sudo systemctl enable --now apache2 mariadb.[3]

• Deploy DVWA:

o cd /var/www/html && sudo git clone

[Link] dvwa.[3]

• Configure DVWA:

o cd /var/www/html/dvwa/config && sudo cp [Link]

[Link] (edit DB creds if needed).[3]

• Initialize in browser:

o Visit [Link] → Create/Reset Database → login

admin:password.[3]

Screenshot Deliverables

• “DVWA running” (DVWA login page in a browser).[3]

• If Docker: “docker run console” (container start output).[7]

Section 3 — DVWA Configuration

Must be HTTP and Security = Low.
 • Login to DVWA as admin:password.[3]

• Go to DVWA Security → set Security Level to Low → Save.[3]

• Ensure access is via HTTP (not HTTPS).[2]

Screenshot Deliverables

• “DVWA Security Low” (DVWA security page).[3]

• “Authenticated DVWA page” (any logged‑in page).[3]

Section 4 — Manual Session Hijacking (Core)

Core attack steps to pass.
Goal: Possession of PHPSESSID grants authenticated access.[2]

Victim steps (Victim‑Linux browser)

1. Login at [Link] (or /dvwa) as admin:password.[3]

2. Open Developer Tools → Application/Storage → Cookies for DVWA origin;

copy PHPSESSID value.[2]

Attacker steps (Kali browser)

3) Browse to [Link] but do not log in.[6]
4) Open Developer Tools → Storage/Cookies for that origin.[6]
5) Create or edit PHPSESSID to exactly match the victim’s value.[2]
6) Refresh and open an authenticated page; confirm access.[2]

Expected Result

• Attacker browser is authenticated as admin without credentials.[2]

Screenshot Deliverables

• “Victim cookie” (PHPSESSID visible; redact if instructed).[2]

 • “Attacker cookie set” (cookie editor showing PHPSESSID inserted).[2]

• “Hijacked session” (attacker browsing an authenticated DVWA page).[2]

Troubleshooting

o Use the same base URL and path on both browsers.[2]

o Check cookie domain/path and that the session hasn’t expired or

regenerated.[2]

o Re‑login on victim to refresh PHPSESSID if needed.[2]

Section 5 — Optional: Capture Cookie with Burp

Only in lab network.
Purpose: Demonstrate side‑jacking on HTTP with an intercepting proxy.[4]

Steps on Kali (Burp Suite Community)

1. Open Burp → Proxy → Intercept → Open Browser; ensure “Intercept is on.”[4]

2. In Burp’s browser, visit [Link] and log in; observe Set‑Cookie:

PHPSESSID in the response and Cookie: PHPSESSID in requests.[4]

3. Copy PHPSESSID from Proxy → HTTP history and reuse in a normal browser
as in Section 4.[4]

Alternative routing

• Configure the victim browser to use Kali as an HTTP proxy ([Link]:8080) if

demonstrating through Kali, or simply use Burp’s built‑in browser as the
“victim.”[4]

Screenshot Deliverables

• “Burp Intercept” (response showing Set‑Cookie: PHPSESSID).[4]

• “HTTP history” (request showing Cookie: PHPSESSID).[4]

Section 6 — Mitigations and Validation
Show impact with evidence.[5]
Apply and verify each defense:

• HTTPS + HSTS

o Configure TLS; confirm cookies sent over HTTPS and include Secure
flag.[5]

o Validate that PHPSESSID is not visible in cleartext traffic.[5]

• Cookie flags

o Set Secure and HttpOnly; consider SameSite=Lax/Strict. Verify in

browser cookie storage.[5]

o Confirm JS cannot read HttpOnly and cross‑site requests are constrained

by SameSite.[5]

• Session lifecycle

o Regenerate session IDs on login/privilege change; logout invalidates

server session.[5]

o Previously stolen cookie should fail after logout/regeneration.[5]

Screenshot Deliverables

• “Cookie flags” (Secure/HttpOnly/SameSite visible in browser).[5]

• “Failed reuse after defense” (hijack attempt fails post‑defense).[5]

Submission Checklist

You must submit a full report detailing the following:

 • A Youtube link video, MAX 3 minutes, showing what you did in order to
implement the attack.
• The steps you’ve taken to implement the project with screenshots. Each
screenshot must have a caption to it.
• Brief explanation of the attack and defense steps.
Include all of the following screenshots Screenshots

• Network/IP screenshots (Kali IP, Victim IP, Connectivity).[6]

• DVWA running (login page; Docker console if used).[7]

• DVWA Security Low and an authenticated page.[3]

• Manual hijack evidence (Victim cookie, Attacker cookie set, Hijacked

session).[2]

• Optional Burp evidence (Set‑Cookie and Cookie headers).[4]

• Mitigation evidence (Cookie flags; Failed reuse).[5]

• Short write‑up: steps taken, what worked, what failed, which defenses
blocked the attack.[5]

Grading Rubric

• Environment (20%): Two‑VM network, DVWA reachable over HTTP, Security

Low.[3]

• Attack (40%): Successful cookie reuse yielding authenticated access.[2]

• Evidence (20%): Clear, labeled screenshots and Youtube Video matching

deliverables.[2]

• Defense (20%): At least two mitigations implemented and validated with

rationale.[5]
Appendix A — One‑Command Quick Start (Docker)

• Victim: sudo apt install -y [Link] && sudo systemctl enable --now docker
&& sudo docker run --rm -it -p 80:80 vulnerables/web-dvwa.[7]

• Attacker: Navigate to [Link] and continue with Section 4.[6]

Appendix B — Burp Quick Steps

• Burp → Proxy → Intercept → Open Browser → login to DVWA → see

Set‑Cookie and Cookie headers.[4]

• Turn Intercept off, use HTTP history to copy PHPSESSID, then perform
reuse.[4]

References

• OWASP: Session hijacking attack.[1]

• OWASP WSTG: Testing for Session Hijacking.[2]

• OWASP: Session Management Cheat Sheet.[5]

• DVWA official repository.[3]

• DVWA Docker image.[7]

• Kali DVWA tool page.[6]

• Burp: Intercepting HTTP traffic and proxy usage.[4]

1. [Link]
2. [Link]
Web_Application_Security_Testing/06-Session_Management_Testing/09-
Testing_for_Session_Hijacking

3. [Link]

4. [Link]
http-traffic

5. [Link]
ml

6. [Link]

7. [Link]