A casual hunt of the day : Open Redirect at one of the largest MNCs
Jazakallah Khair (Thank You) to all the people who have subscribed my stories for updates in Cybersecurity, Penetration Testing and Bug-Bounty Hunting. Just for information, I am a security researcher who find flaws in companies in free-time, and share security related posts, reels and tweets.
So, the web-application that I casually re-conned was, let’s say “https://www.company.com,” and was hanging around looking for parameters for Injection attacks.
After a casual look, I found out that the web-site uses an advertisement banner for sharing information and redirecting the users to it’s internal products as well as external products. Interestingly, as progressed to watch the url redirection, I found out three parameters, out of which one uses tokens for some functionalities , while the other redirected the user to products. BTW, the parameter was like this :
“ https://www.example.com/swt?programId=01eae2ec-0576-1000-bbea-86e16dcb4b79&swtUrl=https://www.internalapp.com?q=:price-asc&sessionId=75drt4736-aad8-4f61-afc7-66cffe16545b1.a90f50424-8945-474f-9214-736c60108203&jarvisId=06cc7cc52-e0be-4d4d-bd13-8c3138c0f5a9 “
After looking at this, my mind was around 60% sure that there is a chance of open-redirection issue here. I fired up the Burpsuite, captured the request, sent it to repeater and started to play with it. Within no time, I found confirmed about the issue. The end point that I found out was “swtUrl” in here, and changed it to google.com :
No doubt, the tokens that were set up were rightly placed, but there were some problems related to tokens as they were not validating, expiring or creating any error such as of “Not Found” or anything as such. So this was indeed a vulnerability.
A very big company, and a small misconfiguration showed that sometimes, automated scanners miss what manual testing can’t. Also, It showed that even though companies are pouring a lot of money in developers getting trained with security, still couldn’t achieve the most impactful outputs.
My research said that the developer added the tokens with respect to products, so that when a single banner with multiple products are touched at right product, the user is redirected to same product over that internalapp web-site. However, there wasn’t any security configuration put at swtUrl parameter. So this was one of the midpoints of failures within the hyperlink.
So I exploited it ethically, and shared the POC with concerned web-app organizer to get it fixed. Don’t know whether they fixed or not, but I learnt that it doesn’t matter if you see tokens jumping around here and there within a URL, what matters is to test and re-test them again and again to make sure the security is put it in right manner or not.
So that’s it on my behalf buddies, and I hope you learnt something from this short write-up. Keep leveling up and keep rocking…!!!!!