open-redirect

Open Redirect Detection

Overview

An open redirect exists when the destination of a server-issued navigation is influenced by the incoming request and is not constrained to the application's own origin. The application answers with a 3xx and a Location header (or a meta refresh, or a server-rendered script assignment) pointing wherever the request asked it to point. The attacker is remote and unauthenticated: they craft a link on the real domain, with the real certificate, and let the victim's own browser carry them to attacker-controlled ground. The gain is rarely the navigation itself — it is what rides along. A redirect on a trusted domain is a phishing primitive that survives link filters and user inspection, and an exfiltration channel for anything the redirecting URL carries (an authorization code, an access token, a session identifier, a reset nonce) — in the forwarded query string, or in the Referer the browser attaches to the attacker's page. This skill finds such redirects by locating every site where a redirect destination is assembled from request data, verifying each one in parallel, and merging the results into <output_dir>/open-redirect-results.md.

What it is NOT

• Client-side navigation from a client-side source (/websec:dom-based): script reads location.search, location.hash, document.referrer, window.name, or an inbound message and assigns it to location, location.href, location.assign(), location.replace(), or window.open(). Test: does the server emit the destination (in a Location header, a rendered <meta http-equiv="refresh">, or a value the server interpolated into the page), or does script read it from the URL and assign it without the server ever seeing it? Server emits → here. Script reads and assigns → sibling. A fragment-only source never reaches the server, so it is always the sibling's.
• Server-side request forgery (/websec:ssrf): the server itself dereferences the supplied URL. Test: who makes the request to the attacker's destination — the victim's browser (this skill) or the application's own HTTP client (sibling)? A next value fetched server-side to render a preview is SSRF; the same value returned as a Location is this class.
• Host-header driven URLs (/websec:host-header): the destination's host comes from Host, X-Forwarded-Host, X-Forwarded-Proto, or a similar incoming header rather than from a parameter, body field, or stored return target. Test: which request element supplies the host — a header (sibling) or a value the application treats as an application-level parameter (here)? Absolute URLs built from req.hostname or $_SERVER['HTTP_HOST'] belong to the sibling even when the path comes from a parameter.
• Authorization-server redirect URI validation (/websec:oauth): a redirect_uri matched by a provider against a set registered for a client. Test: is the check the provider's redirect_uri matching against registered values, or the application's own return-URL handling on an ordinary route? A loose match on the provider is the sibling's finding; an ordinary open redirect that happens to sit on a host registered as a callback is this skill's finding, with the token-theft consequence recorded in Impact.
• Script execution in the victim's origin (/websec:xss): a javascript: or data: destination that the browser executes rather than navigates to. Test: does the payload execute script in the application's origin, or does it only move the browser elsewhere? Report the missing scheme restriction here, note the escalation in Impact, and hand the execution finding to the sibling under "Also observed".
• Cross-site request to a state-changing endpoint (/websec:csrf): arriving at an endpoint cross-site and having it act is that class. Being bounced to an attacker's site after the endpoint runs is this one. The two chain — a state-changing GET with a next parameter is often both — but each is judged by its own owner.
• Not a finding: a destination selected from a fixed map or enum where the request only supplies a key; a value that, after normalisation, is a relative path with no scheme, no authority, and no protocol-relative or backslash-authority form; a redirect to a constant or to a route generated from a fixed route name; an outbound-link interstitial that is intentionally public, carries no credential, token, or Referer from an authenticated page, and does not claim to validate its target.