 Do you see anything wrong with this picture? Look closely. It's not a fake page. There's actually accounts like Google.com in the address bar with a little lock icon. So we're actually on Google's own web page, but maybe it's a little suspicious that Google Docs needs permission to access my Gmail account or my contacts. Actually, wait, why does Google need permission to access any of this? It's all Google. In today's video, we're going to look at exactly what's going on here and how this led to a major security flaw in Google and what you can do to prevent it in your own APIs. Welcome to OAuth in five minutes, a series where we deep dive on various topics around OAuth and OpenID Connect in just five short minutes. I'm your host, Aaron Parecki, and let's get right into it. We're all familiar with these kinds of screens. Sometimes they're called OAuth Consent screens. Sometimes they're called Permissions screens. This is the screen that you see when you're logging into an OAuth application and it's asking for permission to access your account. The idea here is that it actually is intending to inform the user about what the application will be able to do after you log in. So what's going on with this screen here? Well, at first glance, you might not notice, but what happens if you click the little dropdown under Google Docs here? And then this appears. Now you see some random person's Gmail account and also what's docscloud.info. That sounds suspicious now, right? So what's going on here? Well, it turns out this was not necessarily a hack, but more like an exploit. So someone figured out that they could go into the Google Developer website and create a new OAuth application and just call it Google Docs and upload the Google Docs icon. Then Google would issue them a real client ID and a client secret for that application. Then they can go start an OAuth flow by doing the normal process of creating the URL that describes the request. And in that URL will be the scopes corresponding to what this attacker is trying to do, which is read your contacts and send email from your account. Then all they have to do is get one person to click on this link and approve his request. And then the attacker's application is issued an access token with these permissions. So once the attacker has an access token, now they can go and use the real Google API to download that person's contacts and then use the Gmail API to send an email from that person to all of their friends. What's that email going to contain? Well, what about a message like this where it says, so-and-so is shared a file with you on Google Docs? Click here to view it. Then the victim gets his email in their inbox. Now it's not a spam email because it's actually from their friend's real Gmail account because it uses the API. And that's a really important part here is that this is not a spam wave. This was not a spam attack. This was real emails sent from Google to Google using a real access token. So because you would receive this email from somebody you know where it's actually a real email and not a spam email, you would then click that link, okay, open in Docs. And then you're presented with a screen which might look a little bit suspicious, but you're already thinking about Google Docs. So you're probably just going to click okay, especially because you are really on the Google website. It's not a phishing website. And as soon as you click okay, the attacker gets issued an access token for your account and now they can repeat the process to all of your friends. And then it can just keep spreading and spreading. This happened in 2017. And within 40 minutes of this starting, Google tweeted this out, which was, we're investigating this problem. Something is going wrong. We don't know what it is yet, but we're looking into it. Don't click the link. You could see this whole thing unfolding on Reddit where even Google engineers were chiming in on the thread, being like, oh yeah, we're looking into it. Okay, we fixed it. All right, we disabled the client ID. We know what's going on now. We shut it down. The next time anybody clicked that link, then they would just see this error page because the client ID was disabled. But did that actually fix the problem? I don't think it did because really anybody can just do that again, right? Just go make a new app, get a new client ID, new client secret, and start the process over again. What's the actual underlying problem here? There's a couple of parts to it. Google should probably prevent developers from using the word Google in any of their app names they register. That is a good tip for anybody creating an OAuth service with a public API. Make sure that you have a list of words that are not allowed to be used in app names and make sure that list includes your own brand terms. So Google is able to roll that out right away. But I think what this really comes down to is a user experience or an education problem. And this stuff is hard. Like it's hard to teach users what's safe online, but we should be helping them out whenever we can. And I think the reason this spread so quickly was that that permission screen did not actually appropriately convey what was happening. It just said Google Docs and had an icon. It was only when you clicked the little dropdown where you got to see more context about the request like the name of the developer and the URL it would be taken to. So I think that ends up being a pretty important part of this is providing more information to users so that they can make informed decisions. If we look at the screen from GitHub, it looks quite different. It still includes the application name and the icon. But down at the bottom, right below the green button that you're going to click to allow this access, it actually shows the address of the application that you're going to be returned to. And if that appeared on the Google screen, I think a lot fewer people would have clicked it because they would have seen that it looks suspicious sooner. And that's our five minutes. I hope this has been helpful. As always, give this video a thumbs up if you enjoyed it and subscribe for more videos like this. I'm Aaron Pericchi. Thanks for watching and I will see you in the next one.