in one private program at bugcrowd, i came across three different open redirect bug methods.
first
this is an effortless open redirect vulnerability as follows and i reported it to the company.
> https://companyx.com/redirect?url=http://mert.ninja
then they marked as “triaged” and “unresolved” the bug. after a while, they marked it as “resolved” and rewarded me.
second
also asked me to check their fix. i noticed the bypass technique when checking it with backslash () char as follows.
https://companyx.com/redirect?url=https://mert.ninja.companyx.com
so firstly i tried to add a subdomain that includes forward slash(/) char like this mert.ninja/.companyx.com but it was not successful. because they were checking the subdomain’s chars and blocked me for forward slash char. but they didn’t block me when i use back slash char in the subdomain. (trick: browsers convert to forward slash char when it saw back slash char.)
then i reported again and they replied to me as follows.
Hi Mert, I really appreciate you taking a look at this submission to check the fix. You are right that the fix wasn’t complete. We’ll be pushing a fix.
third
after a while, they marked it as “resolved” and i started tampering with it again. i spent ~15 minutes and i thought it was fixed but i came across a bug for this prevention then i bypassed it again successfully as follows.
https://companyx.com/redirect?url=https://mertcompanyx.com
if i add anything to the head of the domain, the open redirect was working again. so an attacker can register a domain like attackercompanyx.com, attacker-companyx etc. he can still use it as a phishing attack. i reported again this technique and they replied as follows.
Sure enough. Thanks again. Your definitely gonna get an invite to our always on program:). Appreciate the retest!
it sounds good, nice community! #bugbounty
(maybe over, maybe it’s not yet.)