Last year in July, I tried to test myself and signed up on Intigriti, a popular bug bounty platform. With college being shut down due to COVID and my job waiting on my college degree, I had spent the free time in lockdown studying different security vulnerabilities in web applications. I figured bug bounty programs would be a good place to put into practice what I had learnt.
The Realization
Bug bounties are tough. They really are. The competition in public bug bounty programs is crazy and it is very difficult to find bugs as a beginner. To add to that, there are professional hunters out there who have built and setup their automation frameworks on VPSs that automate most of their processes. Leaving no low hanging fruits for you as a beginner (Not being salty, they absolutely deserve it for their hard work).
It took me a month to find my first bug on a public program after which I started getting private invites.
The Struggle
I have this habit of using Firefox in Incognito mode to search for stuff and have Burp Suite running in a normal Firefox window when I'm testing any web application. And funnily enough, that habit found me the bug!
I was going through the web app of the program in question, let’s call it target.com from here on. I had tried a number of things on target.com already, but couldn’t find a bug. My failed attempts included finding XSS, SQLi, IDORs, checking the password reset functionality, testing the JWT implementation and a lot of other things. But even after a week of sticking to the same program, no success!
The Accident
I was about to give up on my nth program and move on to the (n+1)th when something happened. I was on my normal browser window, logged in into the application. Burp’s content discovery had found me a bunch of endpoints in the application that were exposing some Javascript files. I had read enough bug bounty writeups where people found access tokens and other sensitive information in JS files. So I decided to go through those files before calling it quits.
One by one, I was copying the endpoints from Burp and opening them in my browser window. Because I was logged in, the application was allowing me to access the endpoints as well. This one time however, I accidentally copied an endpoint from Burp and paste it into the incognito browser window, that I use to Google stuff. That’s when it happened!
Open Redirect
The JS file didn’t load because I wasn’t logged into the web application in the incognito window. The browser took me to target.com’s Login Page. I noticed the URL and found something interesting. The URL looked like this:
https://target.com/login?targetURL=/path/of/js/file.js
Upon login, the application was going to take me straight to the JS file endpoint and not to the Dashboard. It was using the targetURL parameter to redirect me.
I immediately thought this could potentially be vulnerable to Open Redirect. And so, I changed the value of the targetURL parameter to https://maliciouswebsite.com
The complete URL now looked like
https://target.com/login?targetURL=https://maliciouswebsite.com/
I put my login credentials and hit enter. And the application now redirected me to maliciouswebsite.com!
For those who don’t know what Open Redirect is, an Open Redirect is simply when an attacker is able to redirect users from the target web application to another malicious web application controlled by the attacker. In this case, the attacker would be able to redirect the user from target.com to maliciouswebsite.com using the targetURL parameter.
Why is this a Security Issue?
Open Redirect on its own is not considered as a big security issue, especially in bug bounty programs. The most an attacker could do, is lead the user to a malicious phishing website that looks exactly like the target application.
But Open Redirects can be chained with many other security issues to increase their impact. Some chaining methods include:
Open Redirect to trigger XSS (Cross Site Scripting)
Open Redirect to steal tokens (OAuth, JWT Tokens, etc)
Open redirect on Login/Password Reset pages to steal credentials
Open Redirect chained with SSRF (Server Side Request Forgery)
The above chaining methods drastically increase the impact of an Open Redirect Vulnerability. At the time I found the bug, I did not know much about chaining, so reported it just as an Open Redirect.
But I'll leave you with these reports of Open Redirect chained with XSS vulnerability in Twitter and Uber.
For any questions, feel free to reach out on Twitter or Instagram
Until next time.
