Comment by paxys
1 year ago
I work in this space and have dealt with variants of this exact vulnerability 20+ times in the last 3-4 years across a wide range of login providers and SaaS companies. The blog post is correct, but IMO the core problem itself is too far gone to be fixable. Delegated auth across the internet is an absolute mess. I have personally spoken with plenty of Google and Microsoft engineers about this, so I can guarantee they are all already well aware of this class of problems, but changing the behavior now would just break too many existing services and decades-old corporate login implementations.
The "fix" at this point is simply – if you are using "Sign in with XYZ" for your site, do not trust whatever email address they send you. Never grant the user any special privileges based on the email domain, and always send a confirmation email from your own side before marking the address as verified in your database. All the major OAuth providers have updated their docs to make this explicit, as the post itself points out. In fact I'm surprised there even was a payout for this.
I feel as though this is a consequence of organizations not really understanding how complex the space truly is. The way I've watched OAuth2 + OIDC get adopted in various companies was never from a security-first perspective; rather, it's always sold as a "feature": login with x, etc. Even when there are moves to make flows more secure - PKCE, for example - you end up playing a game of "whack-a-mole" with various platforms doing shitty things in terms of cookie sharing, redirect handling, and the like. The fundamentals of 3-legged OAuth2 are sound and there's tons of prior art (CAS comes to mind), but the OpenID Foundation should be tarred and feathered for the shitty way they market and sold OIDC.
OpenID Connect and all its extensions are so high in complexity and scope. The documents themselves are massive and written in a quite hard to understand form. I've implemented many protocols and RFCs so I feel I have some experience.
Because OpenID Connect and OAuth2 are so closely related, I worry that some of this overengineering is making it's way back into new OAuth2 extensions.
I'm worried both will eventually collapse under their own weight, creating a market for a new, simpler incumbent and setting us back another 10 years as all this has to get reinvented again.
My outside impression is that the OIDC folks are highly productive with really strong domain knowledge and experience, but they're not strong communicators or shepherds with a strong enough vision.
The sad thing is that this is the second thing with the OpenID name that's going down this path. The original OpenID concept was great but also collapsed due to their over-engineering.
Agree - you only need to look at things like the hybrid flows to see where things fall apart: why would you issue an id_token that contains user information to a client which hasn't yet fully authenticated itself via a code-to-token exchange with passing it's client_id + secret? If you look at certain implementations, such as Auth0, you'll find that they actually POST that token back at the redirect_uri, since, a) it's at least registered against the client; b) it's not subject to capture as easily. The spec says NOTHING about protecting this info, though.
> Never grant the user any special privileges based on the email domain, and always send a confirmation email from your own side before marking the address as verified in your database
Doesn't this fail if the user registered an account (on google) with the plus sign address, and then signed into your service with that google account before getting the boot? Unless you're sending a verification email for every sign-in...
The idea is that the company's Zoom admin should always specify the exact list of users who are allowed to be in their Zoom account. The email domain should have no bearing. So if you sign in as bob@mycorp.com, and that is a valid corporate account with the right permissions, you are let through. If you try bob+foo@mycorp.com, it should always fail. The pattern of "oh they have a mycorp.com email so they are probably legit" was broken from the start.
This is thankfully less of an issue now since everyone is moving to SAML-based logins and SCIM provisioning.
> This is thankfully less of an issue now since everyone is moving to SAML-based logins...
Hate to break it to you but SAML is same shit different coat of paint, the xml encryption/signature/encoding stuff it pulls makes it just as much a tarpit for bugs and misconfiguration.
SCIM seems pretty decent though to explicitly state who is and isn't on the Guestlist.
What I’ve also seen is integrations with a different OIDC endpoint for company X. It’s still OIDC, but it’s not “sign in with Google”.
This will help, but at the same time will ruin the whole idea of seamless corp users registration in external service, and damage adoption and increase friction.
10 replies →
> Unless you're sending a verification email for every sign-in...
Yes, absolutely do this! This is what Slack does, and what we do at my current employer (defined.net). "Magic link" email + TOTP is pretty slick.
Please don’t do this, or at least try offer normal login alongside it. This is really bad ux. Instead of being able to have my password manager sign me in without me having to do much, I suddenly have to open my email (which I might have closed because I want to focus), go to the email - god forbid I have to wait 10s for it to arrive - and then it opens a new tab for me…
> "Magic link" email + TOTP is pretty slick.
Agreed. But unfortunately it's also highly phishable.
12 replies →
I hate this experience. It's an absolute pain when emails are delayed and sign in fails, or just when some apps fail to persist state when I switch to my email client on mobile.
1 reply →
> Unless you're sending a verification email for every sign-in...
Isn't that your typical 2FA flow?
But in this particular case the attacker will actually receive a confirmation email, so what's the point?
> always send a confirmation email from your own side before marking the address as verified in your database
This would render the login with x feature useless from a user pov.
Would be be useless? Wouldn’t the verification email happen once, then after which you gain all the SSO benefits?
You still get the benefit of not remembering an extra password.
Why couldn't Google prevent signups using domains of Google Apps customers? That doesn't seem like it would break anything.
because the collisions can already exist when someone signs up for google workspace. and what are you going to do, delete those accounts? a lot of those would be personal accounts on educational domains...
That's not a reason to not allow individual signups on @customer.domain AFTER customer.domain is a Google Workspace domain, which is the hole being discussed in the article.
FWIW Adobe actually lets businesses take ownership of individual accounts with the same domain... see https://www.adobe.com/legal/terms.html section 1.4
2 replies →