Open Redirects, in my opinion at least, are a security issue. While not on the level of everything should be dropped and it should be addressed immediately, they do however represent a security risk for your users.
So, what is an Open Redirect vulnerability? This vulnerability occurs whenever you have input which you then use to redirect the user. Most often this takes the form of a query parameter, which specifies the URL to redirect the user to. This is perhaps the most dangerous form since it is trivial to create an exploit and can help enable attacks such as phishing attacks.
Google's Open Redirect
The vulnerability in Google's Open Redirect is in the fact that Google converts URLs into redirects all over its product suite. The most recent example I found was Google Meet. When a link is posted into the chat messages in a Google Meet session, that link is converted to a Google Meet link in the form of:
<pasted-url> is the URL which was pasted. There are other parameters, which I will come to in a moment. Clicking on this link will then take the user to the appropriate URL. Now this is a problem since this suddenly becomes a fantastic tool for phishing! Let's look at the following example:
We've emphasised users to look to the beginning of the URL to validate that the link is legitimate. Well, we see that the domain name in the above URL is
meet.google.com, a legitimate Google domain. So therefore many will incorrectly assume that this link is legitimate. So what happens when you hit this link? Well you are take to a "Google login" page:
However when you look closer you will realise that it is in fact not an authentic Google login page:
The screenshot on the left is the authentic login page. The first give away is the domain name
accounts-google.phishy.info, and the other give away (perhaps not so obvious) is the missing content. So we have a link which contains a Google domain, taking you to a "Google login" page. Bear in mind that most will only look to the URL before clicking on it, not after they have clicked on it (I most certainly would be one of these people).
Now you might be thinking, well this link is generated during a Google Meet session so you at least need to be authenticated and have a valid session. Nope! This works without any authentication and is accessible simply by clicking on the link.
Another point is the additional query parameters. There are additional query parameters which do get generated in this link when it is created in Google Meet, however this vulnerability works without those parameters. What is worse you can provide any parameters and they are simply ignored. Now this is an issue because you can use this to help mask the redirect URL:
Often this URL could be truncated or more than likely, the user will simply not pay attention to it. Phishers are incredibly creative and they will no doubt make great use of this.
Google response to this is that they don't think that Open Redirects are much of an issue. I did report this to them and it was rejected.
Google have even created a page attempting to explain why they believe Open Redirects are not an issue:
Yet when you post the link in something like Twitter and attempt to access the link you are prompted with a warning (kudos to Twitter on this, they've done a great job on this and this is a really great feature):
I do worry, that it is perhaps just myself who views Open Redirects as a security issue. Which is one of the reasons why I put out a poll on Twitter (thank you to all those who took part in it):
Most also share the same view. There were also some interesting comments on the poll, so I would highly recommend that you go and read them for yourself. But ultimately while Open Redirects are not necessarily a significant or critical security issue, they are still a security issue none the less and do represent a risk to your users. Depending on the issue and context, the risk will likely vary. Now the issue with Google's Open Redirect is certainly not something I would lose sleep over, as you have hopefully seen, it does present a risk to Google users. How much of a risk may vary from person to person, depending on who you ask (personally I wouldn't class it as critical). But there is still a concern which would at very least be paid attention to, not simply ignored.
I've had this blog in draft for over a month, and it was only after Google was contacted for their input that my domain has been flagged:
It is in my view that this helps illustrate my point! Why is my domain now flagged if this is not an issue to Google? The fact that this "Deceptive" site was active for a month before it was flagged (likely only because Google was contacted directly, of which I was expecting to happen in any case), illustrates how this issue can be used to help aid phishing. Now I can go ahead and create a new domain and get around this issue temporarily until the new domain is flagged. After which I create a new domain, and then that domain will eventually be flagged. And the cycle continues, and ends up being a game of Whac-A-Mole.
Now it turns out that if you follow the traffic flow using the link above, there are in fact 2 redirects:
The request for the first redirect:
GET /linkredirect?dest=https://accounts-google.phishy.info/ HTTP/1.1 Host: meet.google.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-GB,en;q=0.5 Accept-Encoding: gzip, deflate Connection: close Cookie: NID=204=N6m7GUJA19XWA2iv0emAGB3dtu3azZzwE6EfJKSGzSWCoOSNnIjlNVd8hfcZe904hIyY9NHN87NzROyCZ9KVYjaTVA2jtTs62d00_iGYcI6IsO1unWFZxkFnPgUbqOXRn1SM5Za70lqCWudsCaSk1JS5Il_XSqTq6BdosvTSVZk; S=talkgadget=ctSyYf_8K1G8Zclh4zj4hh1gDYEGhi2r; CONSENT=WP.28e24e Upgrade-Insecure-Requests: 1
And the response for the first redirect:
HTTP/1.1 302 Moved Temporarily Content-Type: text/html; charset=UTF-8 Cache-Control: no-cache, no-store, max-age=0, must-revalidate Pragma: no-cache Expires: Mon, 01 Jan 1990 00:00:00 GMT Date: Thu, 10 Dec 2020 18:26:42 GMT Location: https://www.google.com/url?hl=en-GB&q=https://accounts-google.phishy.info/&sa=D&ust=1607711202666000&usg=AFQjCNHUdDPDfHuKlLF-aw7UEheQtYMARg Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Content-Security-Policy: base-uri 'self';object-src 'self';report-uri /talkgadget/_/cspreport;script-src 'nonce-3B8WM8SGZsjmzjBnkCuzFA' 'unsafe-inline' 'strict-dynamic' https: http: 'unsafe-eval' X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block Server: GSE Alt-Svc: h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43" Connection: close Content-Length: 337 <HTML> <HEAD> <TITLE>Moved Temporarily</TITLE> </HEAD> <BODY BGCOLOR="#FFFFFF" TEXT="#000000"> <H1>Moved Temporarily</H1> The document has moved <A HREF="https://www.google.com/url?hl=en-GB&q=https://accounts-google.phishy.info/&sa=D&ust=1607711202666000&usg=AFQjCNHUdDPDfHuKlLF-aw7UEheQtYMARg">here</A>. </BODY> </HTML>
The request for the second redirect:
GET /url?hl=en-GB&q=https://accounts-google.phishy.info/&sa=D&ust=1607711202666000&usg=AFQjCNHUdDPDfHuKlLF-aw7UEheQtYMARg HTTP/1.1 Host: www.google.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 Accept-Language: en-GB,en;q=0.5 Accept-Encoding: gzip, deflate Connection: close Cookie: NID=204=N6m7GUJA19XWA2iv0emAGB3dtu3azZzwE6EfJKSGzSWCoOSNnIjlNVd8hfcZe904hIyY9NHN87NzROyCZ9KVYjaTVA2jtTs62d00_iGYcI6IsO1unWFZxkFnPgUbqOXRn1SM5Za70lqCWudsCaSk1JS5Il_XSqTq6BdosvTSVZk; CONSENT=WP.28e24e Upgrade-Insecure-Requests: 1
The response for the second redirect:
HTTP/1.1 200 OK Location: https://accounts-google.phishy.info/ Cache-Control: private Content-Type: text/html; charset=UTF-8 Strict-Transport-Security: max-age=31536000 Date: Thu, 10 Dec 2020 18:26:42 GMT Server: gws Content-Length: 364 X-XSS-Protection: 0 Alt-Svc: h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43" Connection: close <HTML><HEAD> <meta http-equiv="content-type" content="text/html;charset=utf-8"> <TITLE>Redirecting</TITLE> <META HTTP-EQUIV="refresh" content="1; url=https://accounts-google.phishy.info/"> </HEAD> <BODY onLoad="location.replace('https://accounts-google.phishy.info/'+document.location.hash)"> Redirecting you to https://accounts-google.phishy.info/</BODY></HTML>
Now there may be a legitimate reason why it was done in such as way. However the sceptic in me does wonder why they have chosen to do this in such as manner. This is a company which let's face it, doesn't have the best reputation when it comes to personal data an privacy. The sceptic in me does wonder if they have perhaps done in this manner to try obtain more personal data? However, I'll leave it up to the reader to draw their own conclusions.
Google appears to use redirects in numerous places, and do not seem too concerned about the potential risks this poses. My advice is be vigilant (which you should in any case, but perhaps a bit more when it comes to Google links), when clicking on or accessing Google links. Tools such as password managers can certainly help, I created a video illustrating how password managers can help prevent phishing attempts. Also make sure that you enable multi-factor authentication wherever possible.
Also as part of this exercise I've created a phishing tool, which takes has a fake Google login page. While there is an input for an email, nothing is actually done with this input, and when the user clicks on the Next button or "submits" their email address it takes the user to a page with further information on phishing. This is designed to be an awareness tool to hopefully help alert users to the dangers of phishing and just how easy it is to fall victim to them. It often just takes the slightest slipup.