Open Redirect

An Open Redirect appears when an application redirects the user to a URL taken from a parameter (?next=, ?url=, ?redirect=, ?newurl=) without validating the destination. On its own it does not compromise the server, but it is a valuable piece: it lends the trust of the legitimate domain to a phishing link (the victim sees the good domain and ends up on the attacker's) and, chained, it helps steal OAuth tokens or reinforce an SSRF.

The test is direct: swap the destination for an external domain and see whether the server responds with a 302 to it.

GET /go?newurl=https://attacker.com HTTP/1.1

When there is a filter, it is almost always a naive blacklist that gets bypassed. If it blocks the dot ., apply double URL-encoding (the server decodes one layer and the validation does not see the dot, but the redirect does); if it blocks the slashes //, exploit that for https domains the browser does not need them; and there is a battery of classic bypasses from the ambiguity of URL parsing:

newurl=https:%252f%252fattacker.com      # double-encoded slashes
newurl=https:attacker.com                # no // (valid for the browser)
newurl=//attacker.com                    # protocol-relative URL
newurl=https://trusted.com@attacker.com  # userinfo: the real host is attacker.com
newurl=https://trusted.com.attacker.com  # suffix: attacker's domain
newurl=https://attacker.com/trusted.com  # trusted.com in the path (substring check)
newurl=https:/\attacker.com              # mixed slash and backslash
newurl=https://attacker.com%2f%2e%2e     # path normalisation
newurl=%09https://attacker.com           # leading control whitespace/tab
newurl=javascript:alert(document.domain) # if the redirect is client-side (DOM)

Chained with OAuth, an open redirect in the redirect_uri (or in state) lets the authorization token/code end up on the attacker's server: the victim authorises at the legitimate provider, which redirects, with the token in the URL, to the controlled destination.

Requirements. The application must redirect to a user-controllable value without restricting it to internal destinations. For the bypass, the filter must be based on a blacklist or a substring check (starts with trusted.com, contains trusted.com) rather than strict host validation.

How to detect it. In the access log, the signature is redirect parameters (url, next, redirect) pointing to external hosts or with suspicious encodings (%252f, @, //) in the value. A 3xx response with a Location to a domain other than your own is the evidence; correlating with phishing campaigns closes the case.

Defence. Do not redirect to arbitrary URLs: use a whitelist of allowed destinations or indices that map to fixed internal routes, and validate the full host (not a substring), rejecting external schemes and authorities. If external exit must be allowed, show an intermediate warning page. It relates to SSRF when the redirect is followed by the server itself.