Chaining an Open Redirect Into SSRF: Bypassing URL Allowlists
An open redirect often gets a low-severity shrug. An SSRF sink that only fetches approved domains may get the same. Put them together and the trusted domain becomes a bounce point into localhost, RFC1918 space, or a cloud service.
The chain works when the fetcher validates only the initial URL and follows Location without validating the next destination.
Find both halves before escalating
For the redirect, use a parameter such as:
https://trusted.example/redirect?next=https://listener.example/canary
Confirm a 30x response with an attacker-controlled absolute Location. JavaScript redirects are less useful because most server-side HTTP clients do not execute scripts. Relative-path redirects can still help if parser tricks or scheme-relative URLs are accepted.
For SSRF, identify a feature that fetches URLs: image import, webhook validation, PDF rendering, link preview, SSO metadata, or “test integration.” Submit your direct listener URL first. Record the source IP, DNS lookups, HTTP method, headers, and whether redirects are followed.
Now submit the trusted redirect URL to the fetcher, with its next set back to your listener. That proves the allowlisted hop can escape without touching internal systems. It also gives clean logs showing request one to the trusted host and request two to you.
Controlled internal proof
Change the redirect destination to a harmless internal candidate only after the external chain is stable. Good evidence includes a known health endpoint, a different response length, or a unique service banner. Avoid port sweeps. Test one or two likely ports and stop when the boundary bypass is clear.
Cloud metadata endpoints deserve extra caution. Some programs forbid access even through SSRF. If allowed, request a non-secret metadata path first and never attach live credentials to the ticket. Rotate or disclose any token through the program's secure channel.
Redirect handling has edge cases worth documenting:
- 301/302 may rewrite POST to GET; 307/308 preserve method and body
- The client may cap redirects or reject HTTPS-to-HTTP downgrade
- DNS is resolved separately for each hop
- Credentials embedded in the first URL may leak to the second host in broken clients
- A URL allowlist may check hostname suffix but ignore the redirect entirely
Tell the chain as two trust failures
The redirect endpoint lets an attacker choose a destination. The fetcher trusts the endpoint's domain, then delegates navigation to it. Your report should include the original submitted URL, redirect response, final request logs, and controlled internal result. Draw the sequence in three lines; no grand architecture diagram is needed.
Severity comes from what the server can reach and read. A blind ping to a public listener is lower than an internal admin API response. The redirect may be separately reportable if it has phishing or OAuth impact, but avoid duplicate noise when its main value is the SSRF bypass.
Fix the fetcher by validating every redirect target after canonicalization and DNS resolution, blocking private/reserved addresses, and disabling redirects where unnecessary. Fix the redirect with a server-side destination allowlist or relative paths. PortSwigger has a focused open-redirect SSRF lab. OWASP's SSRF Prevention Cheat Sheet recommends layered network and application controls. Classify the fetch weakness under CWE-918 and the redirect under CWE-601 when the report tracks both.