Chapter 48 — Hands-on: testing a web application

Why this chapter exists

You've seen the bug classes; this is the workflow for finding them in a running app — legally, in your lab — and the tools that make it efficient.

The toolkit

   INTERCEPTING PROXY    Burp Suite (Community is fine to start) or
                         OWASP ZAP. Sits between browser and app; you
                         inspect, modify, and replay every request.
                         -> the single most important tool. Learn one well.

   BROWSER DEVTOOLS      Network tab (see every request, copy as curl),
                         Application tab (cookies, storage, SW),
                         Console (SOP/CSP errors, quick DOM XSS checks),
                         Debugger (find DOM-XSS sinks).

   RECON                 subfinder/amass (subdomains -- your scope only),
                         httpx (probe alive), katana/gau (crawl/URLs),
                         nuclei (templated checks), ffuf/feroxbuster
                         (content & param discovery).

   TARGETED              sqlmap (SQLi), jwt_tool (JWT), dalfox/XSStrike
                         (XSS), ssrf tooling, Param Miner (Burp ext).

   PASSIVE/SANITY        securityheaders.com, Mozilla Observatory,
                         testssl.sh (Part 7), retire.js / SCA (Ch 47).

   PRACTICE TARGETS      OWASP Juice Shop, PortSwigger Web Security
                         Academy, DVWA, WebGoat, HackTheBox, bug-bounty
                         programs WITH scope. (Chapter 0.6.)

A repeatable methodology

   1. MAP
      - Crawl with the proxy running (browse every feature as a normal
        user). Build the site map: endpoints, params, roles, formats.
      - Note tech stack (headers, cookies, JS bundles, errors, favicon).
      - Identify trust boundaries and where user input reaches a
        parser/interpreter/filesystem/sub-request.

   2. AUTH & SESSION
      - How are you identified? Cookie flags. Session rotation on login.
      - JWT? decode it, check alg/exp/aud. OAuth? check state/PKCE/
        redirect_uri.
      - Logout actually invalidates? Password reset flow. Enumeration on
        login/reset/register (timing + messages).

   3. ACCESS CONTROL  (highest ROI -- OWASP #1)
      - Make TWO accounts (A, B). For every object/endpoint A can use,
        replay it AS B and AS anonymous. Change IDs. (Burp: "Autorize" or
        "AuthMatrix" extension automates this.)
      - Find admin/internal endpoints from JS; call them as a low user.
      - Mass assignment: add role/isAdmin/owner fields to update bodies.

   4. INPUT HANDLING
      - For each parameter: try ' " ` \ ; and observe. SQLi (errors,
        timing), XSS (reflection context), command injection, SSTI
        ({{7*7}}), path traversal (../), SSRF (URL params -> your
        collaborator/OAST endpoint).
      - Test JSON/XML/multipart variants; content-type confusion; HTTP
        method override; parameter pollution.

   5. CLIENT-SIDE
      - CSP present and strict? DOM XSS sinks in the JS? postMessage
        handlers without origin checks? CORS policy (reflected origin?
        credentials?). Clickjacking (frame-ancestors).

   6. BUSINESS LOGIC
      - Negative quantities, price/total tampering, coupon stacking,
        race conditions (parallel requests -> double-spend), skipping
        steps in a flow, replaying one-time tokens.

   7. INFRA / MISC
      - Verbose errors, stack traces, debug endpoints (/actuator, /debug,
        .git/, .env, backup files), default creds, directory listing,
        outdated components (retire.js/SCA), security headers.

   8. REPORT
      - Per finding: title, severity (CVSS + business impact), affected
        endpoint, reproduction steps, request/response evidence, root
        cause, remediation, references. Retest after the fix.

Practice / capstone lab for Part 10 (2-3 hours)

   Target: OWASP Juice Shop, run locally (docker run -p 3000:3000
   bkimminich/juice-shop). Proxy through Burp/ZAP.

   Find and DOCUMENT one finding in each class:
     [ ] Injection (SQLi login bypass or UNION data extraction)
     [ ] XSS (one of reflected / stored / DOM)
     [ ] Broken access control (basket/order IDOR, or an admin API)
     [ ] Authentication/JWT (forge or tamper a token)
     [ ] CSRF or SSRF or CORS misconfig
     [ ] Security misconfiguration (a header, an exposed file, verbose
         error) or a vulnerable component (retire.js)

   For each: write a mini report (the "REPORT" template above) into
   ~/sec-lab/reports/part10-webapp.md.

   Then pick TWO findings and build the FIX in a small local app:
   reproduce the bug, apply the remediation from the relevant chapter,
   write a test that proves it's closed.

Common confusions

"Scanners find the bugs." Automated scanners find some — misconfig, known CVEs, reflected XSS, obvious SQLi. Access control and business logic — the highest-impact classes — need a human with two accounts and a proxy.
"Burp Community is too limited." It's enough to learn the entire methodology above. Repeater, Intruder (rate-limited), Decoder, and the proxy cover most of it.
"Testing = running nuclei." Templates are great for breadth/regression. They don't understand your app's authorization model or workflows.
"I found it, I'm done." A finding without clear reproduction steps, impact, and a remediation is low value. And always retest the fix.
"It's my company's app, I can test prod." You need written authorization and a defined scope/window even internally (Chapter 0.6). Test staging; coordinate.

Check yourself

What is an intercepting proxy and why is it the core tool?
Which vulnerability class gives the highest ROI when testing, and what's the basic technique (hint: two accounts)?
Give the first-pass input characters you'd try on a parameter, and what each might reveal.
Name three "infra/misc" issues you'd check with almost no effort.
What must every finding in a report contain?

Chapter 48 — Hands-on: testing a web application

Why this chapter exists

The toolkit

A repeatable methodology

Practice / capstone lab for Part 10 (2-3 hours)

Common confusions

Check yourself

Further reading

End of Part 10 — Milestone check