Open redirects are sneaky because they don’t break anything outwardly, but they can be used to send users to malicious sites.
Let’s see how Burp Suite can sniff these out.
Imagine a user clicks a link on your site that looks like this: https://your-legit-site.com/redirect?url=https://malicious-site.com. Your site, instead of serving content, just sends the user’s browser to malicious-site.com. That’s an open redirect. It’s a foothold for phishing, malware distribution, or credential harvesting, all under the guise of your trusted domain.
Here’s a typical scenario in Burp. You’re browsing your application, and you notice parameters that look like they might be handling external URLs. Common culprits are parameters named url, redirect_url, next, return_to, or continue.
Let’s say you’ve intercepted a request in Burp Proxy for https://your-legit-site.com/login. The response shows a redirect to https://your-legit-site.com/dashboard?session_id=abc123. Now, you want to test if you can change that redirect destination.
The simplest way to start is manual testing. In Burp Proxy’s HTTP history, find a request that results in a redirect (indicated by a 302 Found or 301 Moved Permanently status code). Right-click this request and select "Send to Repeater."
In Repeater, you’ll see the original request. Look at the response. If it’s a redirect, you’ll see a Location header in the response. For example:
Location: https://your-legit-site.com/dashboard?session_id=abc123
Your goal is to change the value of the Location header (or, more accurately, the parameter that controls the Location header) to an external domain. Find the parameter in the request that seems to be responsible for the redirect. Let’s assume it’s a redirect_uri parameter in the request body.
Original request in Repeater:
POST /login HTTP/1.1
Host: your-legit-site.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
username=test&password=test&redirect_uri=https://your-legit-site.com/dashboard
Now, modify the redirect_uri parameter to point to an external, potentially malicious, site. Use a site you control or a known safe testing site like http://interact.sh (if you’re using Burp Collaborator) or https://google.com.
Modified request in Repeater:
POST /login HTTP/1.1
Host: your-legit-site.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 65
username=test&password=test&redirect_uri=https://evil-site.com/phish
Send this modified request. If the server faithfully redirects you to https://evil-site.com/phish (and you see this in the Location header of the response, or if you’re using Burp to follow redirects and see the final URL), you’ve found an open redirect.
Beyond manual testing in Repeater, Burp Suite’s Scanner can automate this. Ensure the Scanner is configured to check for "Server-side injection" vulnerabilities, which often includes checks for open redirects. You can also create custom scan configurations to specifically target parameters you suspect.
For a more targeted automated approach, you can use Burp Intruder. Select the parameter you want to test (e.g., redirect_uri), right-click, and choose "Send to Intruder." In Intruder, go to the "Payloads" tab. Under "Payload type," select "Simple list." In the payload field, paste a list of common external domains and malicious-looking URLs. For example:
https://evil-site.com/
http://malicious.com/login
https://your-legit-site.com.evil.com/
https://example.com/
http://1.1.1.1/
Run the attack. Watch the results for any responses that show a 302 or 301 status code and a Location header pointing to one of your injected payloads. You’ll be looking for a 200 OK status code on the final redirected URL, which indicates the external site was reached.
A common mistake is assuming all redirects are vulnerable. The key is how the application validates the redirect URL. If it doesn’t perform sufficient validation (like checking against an allowlist of trusted domains, or ensuring the URL starts with / for internal paths), it’s exploitable.
Sometimes, you’ll find a redirect parameter that looks like it’s vulnerable, but the application is only allowing redirects to specific, hardcoded subdomains. For example, it might only allow https://support.your-legit-site.com or https://app.your-legit-site.com. In such cases, you might need to look for other parameters or try more advanced techniques like SSRF if the redirect mechanism is complex.
If you find a redirect parameter like next=/user/profile, and you can change it to next=//evil.com/, you’ve likely achieved an open redirect. The double slash // often causes parsers to treat the following part as a new domain.
The fix is almost always server-side: implement strict validation on the redirect URL parameter. This typically involves an allowlist of fully qualified domain names (FQDNs) or at least a check to ensure the provided URL is within the same domain or a predefined set of trusted domains.
The next challenge you’ll face is detecting SSRF vulnerabilities, which often share similar input vectors as open redirects.