ssrf

Identify parameters accepting URLs or hostnames, set up a callback listener like Burp Collaborator or Interactsh, then submit internal addresses (127.0.0.1, 169.254.169.254) and your callback URL. Confirm SSRF through leaked responses, timing differences, or callback logs.

Use out-of-band detection with a public callback server, Burp Collaborator, or canarytokens.org. Submit your unique callback URL to the vulnerable parameter and check server logs for incoming requests from the target. Time-based delays can also confirm blind SSRF.

Common bypasses include alternate IP representations (decimal 2130706433, octal, hex), IPv6 variations like [::1], URL encoding, open redirects on allowed domains, DNS rebinding with tools like rbndr.us or 1u.ms, and parser confusion with embedded credentials or backslashes.

IMDSv2 requires a PUT request to /latest/api/token to obtain a session token before querying metadata. SSRF exploitation works only if the application supports custom HTTP methods, method override headers, or parameter-controlled request methods.

The methodology references Burp Suite extensions (Collaborator, Param Miner, Turbo Intruder), specialized tools like SSRFmap, Gopherus, and Interactsh, plus network utilities like Netcat and Wireshark for callback detection and protocol analysis.

Only test SSRF on systems you are authorized to assess, such as your own applications or in-scope bug bounty targets. Cloud metadata access and internal network scanning can expose sensitive credentials and may violate laws or program rules without permission.