netsec

1313 readers

1 users here now

Technical news and discussion of information security.

Rules:

Be excellent to each other
Keep it on topic
Absolutely no PII or doxing
No disclosure posts

founded 2 years ago

MODERATORS

t8r@lemmy.world

As if you needed another reason not to ever use SSO to your Google account for anything (mbin.grits.dev)

submitted 2 years ago by mozz@mbin.grits.dev to c/netsec@lemmy.world

11 comments fedilink hide all child comments

For some reason this only just now occurred to me: What's to stop some web site from carefully crafting an imitation of the Google "you need to sign in again" UI, storing your Google password, and storing from the other side the auth cookie from Google, so that it can then poke around through 100% of your Google content including any other site you've signed into with the same SSO login?

This is such a fundamental flaw in the whole concept that it's obviously occurred to people and they've had time to come up with something to prevent it, but I can't see how you could prevent it. Have I missed something? You might have a non-Google URL in the address bar during the faked sign-in, or you could use varying degrees of deception to attempt to make the address bar look legit, but I'd honestly be surprised if more than 20% of people even check the address bar every time they sign in to SSO. I don't.

So what's to make this not work?

all 12 comments

sorted by: hot top controversial new old

[–] slazer2au@lemmy.world 3 points 2 years ago (1 children)

That's not how it works.

When you use SSO to auth the website never sees your account credentials.

The site: Google, here are my SAML codes can you auth this person. Google: cool those SAML codes are correct, hey user what are your Google auth details?
User: here you go Google.
Google: sweet, those are valid. hey site here is a token specifically for you for this user.
Site: welcome user.

At no point does your Google password hit the site and the tokens for other services will not work with a random webapp.

[–] mozz@mbin.grits.dev 5 points 2 years ago

That's not how it works if the website serves you the genuine Oauth code.

If the website serves you a malicious imitation of the genuine Oauth code, which is crafted to make that exactly how it works, then that is in fact exactly how it works.

[–] mspencer712@programming.dev 3 points 2 years ago

My account uses 2FA and my browser remembers my password. If I get a sign in prompt but my browser doesn’t / won’t auto fill my password, I assume it knows something I don’t and I’m immediately suspicious.

Your scenario is absolutely valid and would probably catch a lot of people who don’t think about security.

[–] BradleyUffner@lemmy.world 1 points 2 years ago (1 children)

If this were an actual flaw, it would completely break all of OAuth everywhere. How likely do you think it is that the entire security industry, and all hackers everywhere, would have overlooked something like this?

[–] mozz@mbin.grits.dev 1 points 2 years ago (1 children)

Can I set up a web site and ask you to go do your Google SSO on it? I promise it's legit

[–] BradleyUffner@lemmy.world 1 points 2 years ago (1 children)

I'll take a look at your site, I'm curious to see what it looks like, but I'm not entering any real credentials.

[–] mozz@mbin.grits.dev 2 points 2 years ago (1 children)

I thought you were extremely confident that what I was describing wouldn't work though 🙂

[–] BradleyUffner@lemmy.world 2 points 2 years ago* (last edited 2 years ago) (1 children)

I'm confident there will be some sign that it's a forged OAuth prompt rather than Google's prompt, and I'm not entering credentials into an obviously fake prompt.

[–] mozz@mbin.grits.dev 2 points 2 years ago

Well, that's lucky, because I don't want to sign up for OAuth tokens with Google and then immediately start doing something nefarious with them just to prove a point. 🙂

I looked around a little though, and I was able to find an example of this technique being used for real maliciously "in the wild." My envisioning of it was somewhat different (overriding or obfuscating the URL bar in a real window showing malicious HTML, as opposed to constructing an entire fake window), but the principle's pretty much exactly the same.

I also learned that Google's response, after some not-real-similar attacks which also exploited doing nasty things with real OAuth vendor credentials, was to tighten up a lot on their security on who can have OAuth vendor credentials (which sounds like a pretty sensible approach to me.)

[–] RedditWanderer@lemmy.world 1 points 2 years ago* (last edited 2 years ago) (1 children)

Companies will include an image of your choosing when you enter your credentials to know it's really the host, and that can't be faked really. Obviously people don't notice and a fake website is often enough, but there is a mechanism.

[–] mozz@mbin.grits.dev 2 points 2 years ago

Google Oauth currently doesn't do that
We're doing man-in-the-middle under my proposed scenario anyway (we have to, to defeat 2FA and get a real Oauth token.) It's trivial to show the user the Google-provided image of the user's choosing.