Researcher Tutorials

Open Url Redirects & exploiting them by zseano

About the Creator



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 are simply urls like, which when visited will go from -> 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? I posted this tutorial over a year 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 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 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!

Getting started

To begin with let's start with finding an open url redirect and explore common places to look for them. Let's see what google knows first by using and then playing with the following dorks: (and also try come up with your variants, you never know what you will discover!)
  • inurl:go
  • inurl:return
  • inurl:r_url
  • inurl:returnUrl
  • inurl:returnUri
  • inurl:locationUrl
  • inurl:goTo
  • inurl:return_url

None found? Ok no problem, let's 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. These should be your first places to look, and from there begin dorking for login pages and testing those.

Don't forget to check for hash fragments as well!

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:
  • Grab tokens via mis-configured apps/login flows
    Imagine the following scenario. When logging into 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=// and send our victim the login url, if the website was vulnerable upon successfully logging in, the user will be redirected to our site which enables the attacker to steal their login token.
  • Bypassing blacklists for SSRF/RCE
    Some websites will blacklist some requests to only allow requests to 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)
  • 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.
  • Taking advantage of fileuploads and mobile devices
    This is something I haven't publicly discussed yet but plan on doing so. A lot of sites out there allow you to upload custom files for a variety of reasons. Usually upon visiting it will automatically download that file. So for example, you upload zseano.html and send the link to your friend, it'll download.

    But did you know mobile devices do not respect those headers and instead render the content. But don't get too excited yet and think you've got XSS, mobile browsers won't execute the JS. BUT, you can set clickable links and add all the fancy CSS/HTML.. which can leak the referer. ;)

    So now imagine this scenario. You upload a file to and you notice their login flow has returnUrl which allows for * The file you just uploaded is on, perfect. Set returnurl to and send your victim the link to login. Upon logging in, the user is redirected to your file which renders. Add in a fancy "Click here to continue" link leading to your site and upon clicking, their token is leaked via the referer.

    Now with that said, browsers typically won't leak the referer and this may of been an isolated case for me when i've found a similar issue in the past. But it is always worth mentioning to test either way.. you never know what it may uncover.

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 people run into when testing login flows chained with an open url redirect is not encoding the values correctly. For example, 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.
    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.

These are just interesting bypasses I have discovered. Feel free to reach out and contribute!
  • \/
  • \/\/
  • \\
  • //
  • //[email protected]
  • https://yoursite?
  • //%2F/
  • ////
    (if they just check for **, .computer is a valid tld!
    Treat their domain as subdomain to yours
  • /%0D/
    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`

That's all for now! I hope you enjoyed and will continue to update as needed! :)