Everything You Need To Know About Open-Redirects

Everything You Need To Know About Open-Redirects

Background, Detection, Exploitation, Impact

·

7 min read

Open Redirect

An open redirect vulnerability occurs when an application allows a user to control a redirect or forward to another URL. If the app does not validate untrusted user input, an attacker could supply a URL that redirects an unsuspecting victim from a legitimate domain to an attacker's server.

Example:

abc.com/?url=xyz.com

change xyz.com -> attacker.com

The Need For Redirection?

Often websites need to redirect after a performed action

  • login
  • reset password
  • and others

Server Side Redirection

Header-based being a location-header sent from the server. The benefit with this, for an attacker’s perspective, is that the redirect always works even if JavaScript is not interpreted. A server side function that gets a URL as input will follow the redirect and end up somewhere else.

Pasted image 20210901184834.png

But there is also Client Side Redirection using Javacript or HTML

When the redirect instead happens in Javascript it only works in scenarios where Javascript is actually executed. It might not work for server-side functions, but it will work in the victim’s web browser.

Javascript case would probably be found using the

window.location

While HTML will probably be those meta tags.

<meta>

The Threat

Pasted image 20210901185235.png In this image we see the link pointing to google.com when in reality it will access attacker.com

Now many people will still notice that little trick... but what about this one

Pasted image 20210901185348.png

Imagine the following scenario.

Pasted image 20210901185511.png

Here an innocent link actually directs the user to a file that is downloaded from a malicious website. The file gets downloaded to the unsuspecting user and they think it came from google, after all they get redirected back to googles Thank You page.

Pasted image 20210901185647.png

Other Exploitation Methods

Leaking Tokens

Above we saw a snippet of PHP code which clearly didnt require any validation whatsoever on the input from redirect_to

Take this example from Flask:

In the following example the reset-password url contains both the token and redirect url

image.png

If the redirection gets pointed to an attacker controlled webserver, the referrer header will leak the token

Pasted image 20210901190216.png

SSRF

portswigger.net/web-security/ssrf/lab-ssrf-..

It is sometimes possible to circumvent any kind of filter-based defenses by exploiting an open redirection vulnerability.

In the preceding SSRF example, suppose the user-submitted URL is strictly validated to prevent malicious exploitation of the SSRF behavior. However, the application whose URLs are allowed contains an open redirection vulnerability. Provided the API used to make the back-end HTTP request supports redirections, you can construct a URL that satisfies the filter and results in a redirected request to the desired back-end target.

For example, suppose the application contains an open redirection vulnerability in which the following URL:

/product/nextProduct?currentProductId=6&path=http://evil-user.net`

returns a redirection to:

http://evil-user.net

You can leverage the open redirection vulnerability to bypass the URL filter, and exploit the SSRF vulnerability as follows:

POST /product/stock HTTP/1.0  
Content-Type: application/x-www-form-urlencoded  
Content-Length: 118  

stockApi=http://weliketoshop.net/product/nextProduct?currentProductId=6&path=http://192.168.0.68/admin`

This SSRF exploit works because the application first validates that the supplied stockAPI URL is on an allowed domain, which it is. The application then requests the supplied URL, which triggers the open redirection. It follows the redirection, and makes a request to the internal URL of the attacker's choosing.

Referrer Check Bypass

One way of protecting against CSRF is to check the referrer header to confirm that the request originated from the website itself.

However, with an open redirect it might be possible to trick this by running the CSRF-attack against the open redirect that in turn redirects to the correct page. It will look like the CSRF originated from the open redirect-page, which are hosted on the same domain and is allowed to do such requests.

How To Find Entry Points To Test

  • Burp Proxy history & Burp Sitemap (look at URLs with parameters)

You can use the Site map filter to search for any redirects or forwards used by the Site map.

Click the "Filter" bar to bring up the filter options menu.

Pasted image 20210901193438.png

In this example we will "Filter by status code".

In this instance we are looking for the "3xx" class of status codes. These status codes indicate that further action has to be taken by the user agent to fulfil a request.

Pasted image 20210901193451.png

The "Site map" table should now only show HTTP requests of the "3xx" class.

You can now manually step through these requests to look for “interesting” URLs. These include any items in which the redirection target appears to be specified within a request parameter.

Pasted image 20210901193506.png

  • Google dorking. E.g:

    inurl:redirectUrl=http site:target.com
    site: inurl:redir | inurl:url | inurl:redirect | inurl:return | inurl:src=http | inurl:r=http
    
  • Functionalities usually associated with redirects:

    • Login, Logout, Register & Password reset pages
    • Change site language
    • Links in emails
  • Read JavaScript code
  • Bruteforcing
    • Look for hidden redirect parameters, for e.g.:
/redirect?url={payload}
&next={payload}
&redirect={payload}
&redir={payload}
&rurl={payload}
&redirect_uri={payload}

Responses To Look For When Fuzzing

DOM Based URL Redirection

Tools like Burpsuite can provide assistance in identifying combinations of JavaScript sinks and redirection functions, but these are very often false positives.

To understand DOM-based open redirects, we have to first understand JavaScript sinks. Remember that JavaScript can obtain data directly from the browser.

A URL in your web browser such as example.com/#dashboard, does not send #dashboard to the application. However, dashboard is accessible to JavaScript already loaded in your browser by window.location.hash.

We can confirm this with the browser console:

image.png

If the page uses JavaScript such as the following:

// use substr() to remove the '#' window.location = window.location.hash.substr(1)

This would be open redirection.

An attacker could create a link example.com/#https://www.virtuesecurity.com and phish example users! By using DOM attributes, this vulnerability may even be missed by pentesters who are only looking at Burp traffic.

Tools For Testing


use paramspider than take results and feed it to openredirex

Note : The "FUZZ" is important and the url must be in double qoutes ! 

python3 openredirex.py -u "https://vulnerable.com/?url=FUZZ" -p payloads.txt --keyword FUZZ

or

python3 openredirex.py -l urls.txt -p payloads.txt --keyword FUZZ

OneLiners

OneLiner

1. waybackurls target.com | grep -a -i \=http | qsreplace 'http://evil.com' | while read host do;do curl -s -L $host -I|grep "evil.com" && echo -e "$host \033[0;31mVulnerable\n" ;done

2. subfinder -d http://acme.com -silent | waybackurls | gf redirect | qsreplace 'http://example.com' | httpx -fr -title -match-string "Example Domain'

Tips

?image_url={payload}/.jpg

Try

target.com/?redirect_url=.uk` (or `[any_param]=.uk`).

If it redirects to target.com.uk, then it’s vulnerable! target.com.uk and target.com are different domains.

Payloads and 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/ (use # \ also)
//%2F/yoursite.com
////yoursite.com
https://theirsite.computer/
https://theirsite.com.mysite.com
/%0D/yoursite.com (Also try %09, %00, %0a, %07)
/%2F/yoururl.com
/%5Cyoururl.com
//google%E3%80%82com
java%0d%0ascript%0d%0a:alert(0)
j%0d%0aava%0d%0aas%0d%0acrip%0d%0at%0d%0a:confirm`0`
java%07script:prompt`0`
java%09scrip%07t:prompt`0`

Resources and Cheat Sheets

  1. github.com/swisskyrepo/PayloadsAllTheThings..
  2. pentester.land/cheatsheets/2018/11/02/open-..
  3. portswigger.net/support/using-burp-to-test-..
  4. youtube.com/watch?v=4Jk_I-cw4WE&list=PL..
  5. blog.detectify.com/2019/05/16/the-real-impa..
  6. EdOverflow Open Redirect CheatSheet
  7. cujanovic Open Redirect Payloads
  8. fuzzdb Redirect Url Templates
  9. virtuesecurity.com