Web application penetration testing

Conducting web application penetration testing

Penetration testing (pentest) is a controlled simulation of a real attack on a web application. Unlike security audit, pentest focuses on active exploitation of vulnerabilities and attack chains, not just identifying individual problems.

Types of pentest by knowledge level

Black Box — tester has no information about the system. Maximally realistic external attacker simulation. Takes more time for reconnaissance.

Grey Box — partial information (regular user accounts, general architecture). Most common for web applications.

White Box — full access to code, architecture, credentials. Allows finding maximum vulnerabilities in minimum time.

Methodologies

• OWASP Testing Guide — de facto standard for web applications
• PTES — methodology of entire process
• WSTG — 150+ specific test cases

Phase 1: Pre-engagement

Documents before starting:

• Statement of Work (SoW) — testing scope, exclusions
• Rules of Engagement — allowed techniques, timeframes
• Permission Letter — written testing authorization
• Emergency Contacts — who to call if critical vulnerability found

Phase 2: Reconnaissance (OSINT)

subfinder -d example.com -o subdomains.txt
assetfinder --subs-only example.com >> subdomains.txt
amass enum -passive -d example.com >> subdomains.txt

dnsx -l subdomains.txt -a -aaaa -cname -mx -resp

site:example.com filetype:pdf
site:example.com inurl:admin

curl "https://crt.sh/?q=%.example.com&output=json" | jq '.[].name_value'

waybackurls example.com | sort -u

Phase 3: Scanning and analysis

nmap -sV -sC -p- -T4 --open target.example.com \
     -oA scans/nmap_full

gobuster dir -u https://target.example.com \
    -w /usr/share/wordlists/seclists/Discovery/Web-Content/big.txt \
    -x php,html,js,json,txt -o gobuster.txt

wapiti -u https://target.example.com --modules all -o wapiti_report.html

gau target.example.com | grep "\.js$" | sort -u > js_files.txt
cat js_files.txt | xargs -I {} linkfinder -i {} -o cli

Phase 4: Exploitation

Attack chain example:

1. OSINT: credentials leak found in developer GitHub repo
2. Admin panel: /admin accessible without 2FA
3. Login with found credentials → successful
4. Admin panel: "Export users" function → SQL injection in filter parameter
5. sqlmap --os-shell → Remote Code Execution
6. Extract .env file → AWS S3 keys
7. aws s3 ls → access to database backups

IDOR testing:

session_a = "cookie_user_a"
session_b = "cookie_user_b"

objects_b = [101, 102, 103, 204, 305]

for obj_id in objects_b:
    r = requests.get(
        f"https://target.com/api/documents/{obj_id}",
        cookies={"session": session_a}
    )
    if r.status_code == 200:
        print(f"IDOR confirmed: document {obj_id} accessible")

Race Conditions:

import threading, requests

def apply_promo(session_token):
    r = requests.post("https://target.com/api/promo/apply",
        json={"code": "PROMO50"},
        headers={"Authorization": f"Bearer {session_token}"}
    )

threads = [threading.Thread(target=apply_promo, args=(token,)) for _ in range(10)]
[t.start() for t in threads]
[t.join() for t in threads]

Phase 5: Post-exploitation

Document maximum impact:

• What data is accessible (PII, financial, medical)
• Lateral movement possibility
• Persistence possibility
• Business impact (regulatory, financial, reputational)

Phase 6: Reporting

Report structure:

1. Executive Summary
   - Overall risk assessment
   - Top-3 critical findings
   - Recommendations for management

2. Technical Section
   - Each vulnerability: description → PoC → impact → remediation
   - Screenshots and HTTP traffic as evidence
   - CVSS score for each finding

3. Methodology
   - Tools used
   - Testing timeline
   - What was NOT tested and why

4. Remediation Roadmap
   - P1 (Critical): fix within 24–72 hours
   - P2 (High): fix within 1–2 weeks
   - P3 (Medium/Low): next release

Retesting

After vulnerability fixes, retesting specific findings is conducted.

Timeline