Security · Topic 17 of 23 · Part III — Pentesting in depth

Web application testing in practice

Web applications are the dominant attack surface — and the dominant category of work. This topic gives the methodology, the vulnerability classes, and the toolchain.

Syllabus: Aligned to PTES §4–§6 and OWASP WSTG, scoped to web applications.

Topic 17 · Web pentesting

One methodology. Dozens of patterns. One workbench.

By the end of this topic you can:

Plan a web-application pentest with a structured methodology aligned to OWASP WSTG
Map the application's surface: pages, endpoints, parameters, technologies, authentication state, roles
Recognise the major vulnerability classes and the techniques each enables
Use an intercepting proxy as the central web-pentesting workbench
Capture web-application findings in evidence appropriate for client reporting

What web application testing is

Evaluating a web application's security by interacting with it as an attacker would. The application is treated as a system whose entry points accept untrusted input and produce side effects — data reads, data writes, calls to other systems.

Defining surface HTTP(S) traffic — every request and response between browser and server.

Defining tool An intercepting proxy that lets the tester see and modify every request and response. Almost all web pentest activity happens with a proxy in the middle.

Methodology: the OWASP WSTG path

The OWASP Web Security Testing Guide (WSTG v4.2) organises testing into twelve categories:

1. Information gathering — fingerprint, identify entry points, map endpoints
2. Configuration & deployment — server, framework, infrastructure
3. Identity management — registration, enumeration, lifecycle
4. Authentication — login flows, MFA, password reset
5. Authorization — IDOR, path traversal, access-control checks
6. Session management — session ID handling, expiration, fixation

7. Input validation — the injection family (XSS, SQLi, command, etc.)
8. Error handling — information leakage
9. Cryptography — at-rest, in-transit, token security
10. Business logic — workflow abuse, race conditions
11. Client-side — DOM XSS, CSRF, clickjacking, postMessage
12. API testing — REST / GraphQL / gRPC concerns

Scope determines focus — the WSTG gives a checklist against which coverage can be measured.

Mapping the application

1Technology ID
Server headers, error pages, cookies, response timings, CDN/WAF

2Endpoint enumeration
Crawl via proxy; brute-force dirs/files (ffuf, feroxbuster); admin paths, backup files, API docs

3Parameter enumeration
Every parameter per endpoint — including hidden, JSON, header, and OData

4Auth states
Test as anonymous then low-privileged then higher roles — each state exposes different surface

Output: a working sitemap. The proxy builds it automatically; interpretation is human.

Vulnerability classes — injection family

Untrusted input flows into a privileged interpreter and changes its semantics.

Type	Interpreter	Real impact
SQLi	SQL engine	Data exfil, auth bypass, sometimes RCE via DB features
Command injection	OS shell	Immediate RCE
SSTI	Template engine (Jinja, Twig, Freemarker…)	RCE through engine primitives
NoSQL injection	MongoDB, CouchDB…	Auth bypass, data exfil
XXE	XML parser	File read, SSRF, sometimes RCE

Fix shape Parameterization, escaping, or eliminating the interpreter from the path.

Vulnerability classes — access control

Broken authentication

Account enumeration (distinct error messages per outcome)
Credential brute force — no rate-limit or lockout
MFA flaws — bypassable via response manipulation
Password reset flaws — predictable tokens, no expiry
JWT/cookie forgery enabling auth bypass

Broken access control

IDOR — GET /api/orders/12345; change the number, get another user's data
Function-level authorization missing (admin endpoint accessible without role)
Privilege escalation via parameter tampering (role=admin)
Path traversal in file-access endpoints

Access control flaws are most often missed by automated scanners and most often present.

Vulnerability classes — further patterns

SSRF

Application makes outbound requests; URL is partly user-controlled. Attacker points at internal systems — cloud metadata, internal services, file:// URLs. Impact: cloud-credential theft, internal service interaction.

XSS

Reflected, stored, DOM-based, mutation-based. Impact: session hijacking, credential theft, forced actions in the victim's browser. HttpOnly cookies and CSP reduce impact but misconfigurations are common.

Deserialization

Application deserializes an attacker-supplied object (Java, .NET, PHP, Python pickle) without validation. Working exploit chains (ysoserial) yield RCE.

Business logic & race conditions

Simultaneous requests bypass single-use restrictions; workflow states skipped or reordered. Most-missed by tools — most rewarding to find.

Modern client-side & API patterns

JWT / OAuth / CORS

JWT: algorithm confusion ("none"), weak signing keys, key confusion (RS256 → HS256)
OAuth / OIDC: open redirects in redirect_uri, missing state parameter, implicit-flow weaknesses
CORS: Allow-Origin reflecting attacker domain with credentials
CSRF: SameSite mitigates but many configurations remain vulnerable

API-specific (OWASP API Top 10)

BOLA — missing object-level authorization (API equivalent of IDOR)
Excessive data exposure in API responses
Lack of resource limits (DoS via unbounded queries)
GraphQL: introspection in production; nested-query DoS
Mass assignment / overposting (BFLA)

The intercepting proxy as workbench

Both Burp Suite (Community and Professional) and OWASP ZAP provide:

Full request / response capture and modification
Application sitemap maintenance
Repeater — replay and modify any request
Intruder / fuzzer — automated parameter fuzzing
Active scanner as a baseline
Extensions for specialised capability (Authz, JWT Editor, Hackvertor)

Burp Pro adds Collaborator for out-of-band detection (blind SSRF / XXE / SQLi).

Workflow Browse app through proxy → sitemap builds → run automated scan as baseline → methodically walk WSTG categories for each endpoint and parameter.

Key insight Most findings come from Repeater and Intruder — not from the automated scanner.

Multi-user testing and automation

Testing as multiple users

A common omission: testing as only one user. Authorization bugs reveal themselves when comparing "as user A" vs. "as user B" performing the same action.

Discipline: keep two proxy profiles authenticated as different users; for each request ask: would this work sent as the other user?

Burp Match & Replace or the Authz extension automates this.

Specialised tools

sqlmap — automated SQLi detection & exploitation
nuclei — template-driven scanner; known issues at scale
ffuf / feroxbuster / gobuster — content discovery
wpscan / joomscan — CMS-specific
Postman / Insomnia — API exploration

Tools generate candidates; humans verify and contextualise.

Evidence for web findings

Element	What it must contain
Endpoint affected	HTTP method, full URL, parameter name
Request	Full HTTP request demonstrating the issue, sanitized of secrets
Response	Full or relevant excerpt showing the impact
Reproduction steps	Exact steps a developer with curl / Postman / Burp can follow
Impact analysis	What an attacker can do in this application's context — not a generic CWE description
Severity	Justified with reference to the impact analysis
Remediation	Specific to this application's framework and language

Most common weakness Missing exact reproduction steps. Developer cannot reproduce → finding is doubted → engagement loses credibility.

Check — writing a finding title

Scenario

A finding's title is "XSS on the search page". Rewrite it to convey impact rather than just technique.

Reveal answer

Bad: names the technique and location but not the impact. Better: "Reflected cross-site scripting in product-search parameter enables session hijacking of authenticated users" — names the vulnerability, the parameter, and the consequence. The client needs to know whether this is an annoying nuisance or an account-takeover vector. The title delivers the verdict; the body delivers the evidence.

Check — WAF as a substitute for pentesting

Scenario

A client says: "We already use a WAF; do we need a web pentest?" How do you respond?

Reveal answer

A WAF blocks known attack patterns — it does not fix underlying vulnerabilities. Pentesting finds: (1) vulns the WAF does not pattern-match; (2) WAF bypass techniques (encoding, alternative syntax); (3) authorization flaws and business-logic issues invisible to any WAF; (4) origin-direct exposure that bypasses the WAF entirely. WAF is mitigation; pentest measures the actual vulnerability surface.

What you take home

Web applications are the dominant attack surface; OWASP WSTG is the structured methodology
Map the application fully before testing — technology, endpoints, parameters, auth states
The injection family shares one pattern: user input changes interpreter semantics
Access-control flaws (IDOR, function-level auth) are scanner-blind and extremely common
The intercepting proxy is the workbench; most findings come from manual Repeater work
Test as multiple users — authorization bugs are invisible otherwise
A finding without exact reproduction steps will be doubted

Next: Topic 18 — Post-exploitation & kill-chain synthesis. Chains connect individual findings into impact narratives.

END · TOPIC 17

Methodology first. Patterns second. Proxy always.

Review the OWASP WSTG category list before the next session.