Find Open Redirects on a Domain

Overview

An open redirect is a small bug that makes other attacks work. It lends your domain to a phishing link, it slips past an allowlist in an OAuth flow, and it turns a harmless-looking URL into one a user has no reason to distrust. Nobody tracks redirect parameters, because individually none of them look like a vulnerability.

This enumerates them from the application's own history and confirms which actually redirect off-site. You get the endpoint, the parameter, and the payload that moved the browser, which is enough to fix it without a reproduction call. It belongs in the same standing sweep as the rest of your offensive security checks, because redirect parameters get added by feature work, not by security work.

Pointing one detector at a URL list you already have is a smaller job than this. The candidate list here is built by the run: every archived URL recorded for the domain and its subdomains, deduplicated down to distinct parameter shapes, then filtered to the names that suggest redirection. Two detectors test that same list in parallel, so a case one of them handles poorly is still caught by the other. On a schedule, the confirmed list becomes a diff, which is where a parameter added last sprint shows up.

Pipeline

1. Read the target domain.
2. gau collects archived URLs.
3. urldedupe removes duplicates that differ only by value.
4. Parameters whose names suggest redirection are kept, and the rest discarded.
5. qsreplace substitutes canary payloads into each candidate.
6. oralyzer and nuclei redirect templates test the candidates in parallel, so a case one detector misses is caught by the other.
7. Confirmed redirects are written to a PDF report.

Inputs

• Target. The domain to sweep. Archived URLs for the domain and its subdomains are all analyzed, so one entry covers the estate rather than one host. Use a domain you are authorized to test.
• Redirect parameter names. The names the filter step treats as candidates. The default list covers the usual suspects, and the step is a script, so you can add the parameter names specific to this application.
• Canary payloads. The off-domain destinations substituted into each candidate. Point them at a host you control, which is the safe default and also makes a confirmed hit unambiguous.

Outputs

• Confirmed redirects. The endpoint, the parameter, and the payload that moved the browser off the origin.
• Candidate parameters. Every redirect-shaped parameter the filter kept, confirmed or not, which is the list to re-test after a code change.
• Archived URL inventory. The deduplicated set of URLs recovered for the domain, useful well beyond this check.
• PDF report. The whole run in one file, ready to attach to a ticket.

Sample output

From a completed run against example.com.

gau recovered 9,412 archived URLs for the domain and its subdomains. 300 of them carry a redirect-shaped parameter and survive the filter. Candidates look ordinary, which is the point:

oralyzer requests every combination and reads where the response points:

[-] http://example.com/.well-known/webfinger?r=FUZZ/https://example.com [404]
[-] http://example.com/.well-known/webfinger?r=FUZZ///example.com [404]

Nothing bounced off the origin on this run, which is the result you want. A finding names the parameter and the payload that left the origin. Redirects that stay on-domain are not reported, because they are the intended behaviour.

FAQ

Does this exploit anything?

No. It substitutes a canary value into a parameter and reads where the response points. Nothing is chained onto a confirmed redirect, which is what makes it safe to run against production.

Why mine archived URLs instead of crawling the site?

A crawl only reaches what the application links today. Archives hold parameters from older releases that are frequently still routed, and those are the ones nobody is checking.

Why run two detectors over the same candidates?

The two disagree at the edges, on encoded payloads and protocol-relative targets among others. Running both against one candidate list costs a single extra pass and closes the gap between them.

Is a redirect that stays on the domain reported?

No. On-domain redirects are the intended behaviour, so only destinations that leave the origin reach the report.

What does running it on a schedule buy?

Redirect parameters arrive with feature work, not with security work. A recurring run against the same domain turns the confirmed list into a diff, so a newly added parameter is visible as new rather than buried in the same list as last month.

Related workflows

• Find Reflected XSS on a Domain. Reach for this instead when the reflected parameter lands in the page body rather than in a Location header.
• Find SSRF in HTTP Parameters. Reach for this instead when the URL parameter is fetched by the server rather than handed to the browser.
• Typosquat and Look-alike Domain Scanner. Reach for this instead when the phishing chain you are tracing starts with a look-alike domain rather than your own redirector.