Thanks for your comment Steven!
I think Open Redirects can or cannot be considered a vulnerability depending on the context of their use.
So, if a page’s intended purpose was to redirect you — we have seen a lot of Gmail / Google Images links for example, rewritten to something like:
When in fact, it’s intended purpose is to ultimately redirect you to www.accesshq.com/test-your-technology/.
Google AMP totally takes advantage of Open Redirects, if you will:
(Sorry, offtopic news but the only link I could readily find)
So technically, one could create an AMP-powered phishing website and use Google’s /amp/ redirector to exploit it…
Medium and Facebook do something similar when redirecting you to external websites — perhaps to check if the URL is reported as Suspicious/Phishing against a database.
But… at that point it becomes debatable — if we going to selectively classify certain legitimate usages of open redirects as a non-vulnerability and others as a vulnerability — when in practice, both of them are visually identical to an end user, then perhaps open-redirect is not a critical vulnerability.
In the case I wrote about, StartupTree’s Login page which was supposed to redirect a user to their Dashboard, could be exploited to redirect them to a phishing page, e.g. one that looks like StartupTree but asks for the user’s SSN or billing information. Now, one could argue, if StartupTree had also used a URL redirector on certain portions of its website and its very purpose was to redirect to external URLs — to an end user who is not so tech savvy, visually both of the following URLs will trick them into believing that clicking either of the below links will lead to StartupTree’s page — except the first one is a misuse of the Open Redirects feature, another is a legitimate use (non-phishing). Both can be exploited, or be dismissed as a non-vulnerability:
So, the assumption here is that our user is savvy enough to pay attention to the address bar after the redirect has taken place. It may not be a reliable option and I’m not so convinced by Odoo’s suggestion regarding SSL certificates. Even phishing pages with similar sounding domain names (e.g. imagine https://startuptree-payments.processing-page.tld/ ) can trivially obtain SSL certs for free using Let’s Encrypt. An end-user might be savvy-enough to pay attention to the address bar URL changes, but to expect them to “not believe” the presence of a padlock icon as secure; or for them to actually open and read the SSL certificate particulars is being too trusting of the user and frankly complacent as a security professional — I think as a security community we did a terrible job: for decades we first told the users “pay attention to SSL/HTTPS. It’s secure! You are secure!” and now Let’s Encrypt/Google’s SSL Everywhere initiatives are voiding that premise among technologists by encouraging every webpage to move to SSL to ensure confidentiality (of course, an end-user who is out of the loop has not been communicated this properly).
The downside? The end-user has no clue now if the “padlock” alone means secure or not — depending on their level of awareness. Also, a lot of the times even legitimate websites and banks use funny sounding domain names which may seem to have no relation whatsoever to the legitimate banking institution.
For example, http://accountonline.com (no SSL either!) is actually Citi’s official credit card management website — where users are actually supposed to login using their legitimate credentials.
TD Bank has a similar problem: https://onlineaccessplus.com/TDBank/login.htm
Now, coming to rewards… as vulnerability reporters we gotta do what’s right — and most of the time monetary compensation is neither an expectation nor an incentive to hack, ethically ;-)