exploit-chaininglisted

# Exploit chaining & impact amplification ## When it applies You have bugs that are individually "meh" (self-XSS, an info leak, an open redirect, a weak CSRF) and need to turn them into something a program pays for — or a pentest foothold that needs several bugs stacked. ## Why it works Impact is compositional. One bug supplies a precondition another needs: a leak provides the id IDOR needs; an open redirect makes OAuth leak a token; SSRF reaches the metadata service that yields cloud creds. The chain's severity is the *end* impact, not the weakest link. ## Method 1. **Inventory every finding** with what it gives and what it needs (primitive in / out). 2. **Look for matches**: does bug A's output satisfy bug B's precondition? Common chains: - self-XSS + login-CSRF / cookie-fixation → land XSS in the victim's session. - open redirect + OAuth `redirect_uri` → steal the authorization code → ATO. - IDOR/info-leak → user id/UUID → BOLA on another endpoint. - SSRF → `cloud-imds-ssrf` → IAM creds → cloud impact. - file upload (stored) → XSS/SSRF/RCE depending on how it's served. 3. **Build the shortest reliable path** to the highest impact; script the PoC end-to-end. 4. **Write the narrative**: state the end impact first, then each link with its role, so a triager sees severity immediately (see `reporting-bug-bounty-writeup`). ## Gotchas - Don't over-chain — the simplest path to real impact is more credible and reproducible. - Each link must be reliable; a flak