Creator

Me

zseano
 


About Hey! I'm zseano and I run BugBountyNotes. I do bugbounties full time and I managed to reach the top 10 on bugcrowd in just 8months from one program. I am lucky to attend live events by HackerOne and this is what inspired me to create this! :) I specialise in webapp testing and I love helping others. Feel free to reach out

Open Url Redirects & exploiting them


I'm sure by now you've heard of an open url redirect, but if you haven't: Open url redirects are simply urls like https://www.example.com/?go=https://www.google.com/, which when visited will go from example.com -> google.com. Generally they are classed as low impact and some programs even list them as Out-of-scope and not accepted. So what can we do actually do with them and should you ignore them?

I posted this tutorial originally over 3years ago when it was what I could call an "interet-wide" issue because when Facebook released their apps they were not forcing developers to set their whitelist correctly. This meant a developer setting their redirectURL as example.com could of allowed for all subdomains also. Lots of sites adopted "Login with Facebook" on their site, so all that was needed was an open url redirect vulnerability on the target and you could achieve account takeover. Since most companies consider them as low priority you can imagine they were very easy to find!

Since then, Facebook and other 3rd party login developers have made considerable changes to prevent such attacks, but can we actually still do something with an open url redirect? Let's explore!

Finding open url redirects

To begin with let's start with finding an open url redirect and explore common places to look for them. I will always start with dorking since Google knows more about a target than me, so let's see what google knows first by using site:example.com and then playing with the following dorks: (and also try come up with your variants, you never know what you will discover!)

  1. inurl:go
  2. inurl:return
  3. inurl:r_url
  4. inurl:returnUrl
  5. inurl:returnUri
  6. inurl:locationUrl
  7. inurl:goTo
  8. inurl:return_url

None found? Ok no problem, lets start using their site and look at common places. From my experience most sites usually redirect the user after logging in, logging out, password change, signup etc and handle this from an url parameter. One key place people miss is links in emails. (These are usually handled by a third party :D). These should be your first places to look, and from there begin dorking for login pages and testing those.

Don't forget to test your parameters as hash fragments as well as testing mobile user agent!

Using the open url redirect

By this time we would of found atleast one open url redirect, and if not, get back to hunting! ;) So once we do actually have a valid bug, what can we do? Below are the most common things I will try with an open url redirect:

  1. Grab tokens via mis-configured apps/login flows

    Imagine the following scenario. When logging into redacted.com you notice in the url returnto=/supersecure, and after successfully logging in, the website redirects to /supersecure?token=39e9334a with your login token, and then to the main website. So this means if we set it to returnto=//myevilsite.com and send our victim the login url, if the website was vulnerable upon the user successfully logging in, the user will be redirected to our site which enables the attacker to steal their login token.

  2. Bypassing blacklists for SSRF/RCE

    Some websites will blacklist some requests to only allow requests to theirsite.com. Armed with an open redirect on their domain, depending on their framework and how they handle redirects, you can sometimes bypass their blacklsit and achieve SSRF or RCE (depending on the circumstances)

  3. XSS via javascript:alert(0)

    This does not work everytime and is dependent on how they are redirecting. If it's a 302 redirect then it will not work, but if they are redirecting via javascript then it will work.

    <script>
    top.location.href='reflectedhere';
    </script>

Common issues and bypasses

I run into filters trying to prevent third party redirects all the time. However before even thinking about trying to bypass the filter, one of the most common issues researchers run into when testing login flows chained with an open url redirect is not encoding the values correctly. For example, https://example.com/login?return=https://mysite.com/. The website / browser may get confused with how the return parameter is formatted so it always good to try just normal encoding, and failing that, double encoding. See below for an example:

https://example.com/login?return=https%3A%2F%2Fmysite.com%2F
https://example.com/login?return=https%3A%2F%2Fexample.com%2F%3Freturnurl%3D%2F%2Fmysite.com%2F

Notice we've got two redirects in one? We need to double encode the last redirect so the browser decodes it last and redirects. Sometimes if you don't encode properly the browser won't redirect correctly.

Some Useful Payloads

Below are some useful payloads to help you understand how a sites filter may be working.

\/yoururl.com
 \/\/yoururl.com
\\yoururl.com
//yoururl.com
//[email protected]
https://yoursite?c=.theirsite.com/
https://yoursite.com#.theirsite.com/
https://yoursite.com\.thersite.com/
//%2F/yoursite.com
////yoursite.com
https://theirsite.computer/ (if they just check for *theirsite.com*, .computer is a valid tld!)
https://theirsite.com.mysite.com (Treat their domain as subdomain to yours)
 /%0D/yoursite.com (Also try %09, %00, %0a, %07)
  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`
/%2F/yoururl.com
/%5Cyoururl.com