Open Redirects - Payload List vs Manual Testing

 

In order to bypass a fix for a open redirect a second time, you may need to get creative with your payload list.

The original issue was exploitable with something like:

Referer: https://mybadsite.com#whitelistedsite.com

After the security patch, it no longer worked. Until I combined it with another payload:

Referer: https://whitelistedsite.com@mybadsite.com#whitelistedsite.com

(Note that whitelistedsite.com@mybadsite.com didn't work on it's own, so that's why it was important to combine the two)

Microsoft ID Open Redirect

Recently I submitted a Microsoft Bug Bounty report for an Open Redirect vulnerability in their Identity product. I found it by searching for keywords in intercepted traffic in Burpsuite like "redirect", "dest", "url", etc. The finding was rejected by their security team, and I have approval to post about it here. I can understand why this might be considered an acceptable risk; it happens during logout, so no credentials can automatically be passed onto an attack server in this way. It would definitely require social engineering effort to exploit it. I tried out setoolkit to spoof the sign-in page and redirect them there (by spoofing the page URL that ends with prompt=sign-in and not none or select_account, so that both username and password can be collected, otherwise it auto-populates the username). (However, there are already protections against changing a similar parameter for their sign-in process, so I'm not sure why that functionality wouldn’t be extended to sign-out as well...)

Edit the URL to redirect to ATTACKSERVER/signinGET.html, where the spoof page is located:

User logs in:

Page sends credentials as parameters:

Attacker can view credentials: