Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google’s OAuth login doesn’t protect against purchasing a failed startup domain

trufflesecurity.com

Post reply on HN
Print view View original

291–297 of 297 posts

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#291

Post by nodamage »

radlad wrote: post #109
stackghost wrote: post #96

Earlier quoted context omitted.

>Then, the impostors in step #3 create a different google account with the same domain, and Google says "yeah, these are definitely the same guys as before", even though Google is fully capable of discerning that that is not the case; these are different people with a different workspace account, different names, different payment information, and so on, but Google is saying that if you're holding the domain you are…

Traditionally, SAML / OIDC trust is established using public/private keypairs. Each IdP/SP pair gets a unique combination. In this case, a domain changing hands would not allow the new owner to gain access to the old owner's accounts. In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application. See the distinction between "public a…

> In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application.

There are plenty of use cases where this is appropriate. If you wanted to allow users to login to Hacker News with their Google accounts you would use this option because you do not care what workspace they belong to.

> Some applications (e.g. Tailscale) take advantage of the public Google OAuth API to provide private internal corporate accounts.

This is a misuse of the public Google OAuth API. Your first link clearly states: "A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." In other words it is intended for scenarios where you want to allow access to users outside your workspace.

> Instead, Google instructs you to look at the "hd" parameter, specific to Google, to determine the Google Workspace a given user belongs to for security purposes.

According to your second link the "hd" parameter only tells you what domain the user belongs to, it does not tell you what workspace the user belongs to.

> You can avoid this issue by using a custom Google OIDC IdP configured for internal access only in your applications, rather than using a pre-configured public Google OIDC IdP

So Google offers an OAuth integration option that actually restricts access to your specific workspace. Choosing to ignore this option and instead integrating with the option designed for public access from all Google accounts, and then calling it a vulnerability when someone can login with an account from another workspace, is frankly, absurd.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#292

Post by DrillShopper »

dragonwriter wrote: post #281
DrillShopper wrote: post #165

Earlier quoted context omitted.

In a rational world the remedy would be to sue Google for exposing your payroll information.

Google is neither the party holding the payroll information nor the party that chose to make it available on terms that are insecure against loss of control of the domain, why would it be rational for them to be liable?

Because they're running the faulty auth

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#293

Post by grepfru_it »

jedberg wrote: post #172
grepfru_it wrote: post #136

Earlier quoted context omitted.

Part of my company dissolution process is to renew the domain name for 10 years to prevent exactly this

Is the hope that this sort of attack is just less useful in 10 years? What happens after 10 years?

Common sense would dictat that you have sunset your business by this time.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#294

Post by radlad »

nodamage wrote: post #278
radlad wrote: post #277

Earlier quoted context omitted.

Bingo! Now looking back to your original comment, this is what I was trying to clarify: > I agree, I don't think this is a problem with Google's Oauth implementation, it's a problem with the service providers who authenticate users via the mere existence of an email address ending in @company.com without checking if the email address actually belongs to an active employee. It's a problem with Google's public OAuth im…

> despite Google's docs stating that this is a valid use. :) I don't think Google's docs actually say this. I assume you are referring to the "hd" claim, but that only says: "The domain associated with the Google Workspace or Cloud organization of the user. Provided only if the user belongs to a Google Cloud organization. You must check this claim when restricting access to a resource to only members of certain domai…

>> I think certain service providers might have made the assumption that if a user belongs to a certain domain that also means they belong to a certain workspace, but that is clearly not a valid assumption.

> If you need to validate that the ID token represents a Google Workspace or Cloud organization account, you can check the `hd` claim, which indicates the hosted domain of the user. This must be used when restricting access to a resource to only members of certain domains. The absence of this claim indicates that the account does not belong to a Google hosted domain.

https://developers.google.com/identity/gsi/web/guides/verify...

FWIW, I worked on SSO products for nearly 5 years and am pretty familiar with this space.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#295

Post by radlad »

nodamage wrote: post #291
radlad wrote: post #109

Earlier quoted context omitted.

Traditionally, SAML / OIDC trust is established using public/private keypairs. Each IdP/SP pair gets a unique combination. In this case, a domain changing hands would not allow the new owner to gain access to the old owner's accounts. In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application. See the distinction between "public a…

> In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application. There are plenty of use cases where this is appropriate. If you wanted to allow users to login to Hacker News with their Google accounts you would use this option because you do not care what workspace they belong to. > Some applications (e.g. Tailscale) take advantage…

> This is a misuse of the public Google OAuth API. Your first link clearly states: "A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." In other words it is intended for scenarios where you want to allow access to users outside your workspace.

> According to your second link the "hd" parameter only tells you what domain the user belongs to, it does not tell you what workspace the user belongs to.

From the docs:

> If you need to validate that the ID token represents a Google Workspace or Cloud organization account, you can check the `hd` claim, which indicates the hosted domain of the user. This must be used when restricting access to a resource to only members of certain domains. The absence of this claim indicates that the account does not belong to a Google hosted domain.

https://developers.google.com/identity/gsi/web/guides/verify...

Note also that even Google conflates "domains" with "Google hosted domains" with "Google Workspace or Cloud organization accounts."

> Choosing to ignore this option and instead integrating with the option designed for public access from all Google accounts, and then calling it a vulnerability when someone can login with an account from another workspace, is frankly, absurd.

At this point, if you still believe calling this a vulnerability is absurd, I don't think there's anything more I can say to convince you. Google paid out the bounty because they didn't believe it was abusrd.

I personally think that the best counterargument to calling it a vulnerability is: "well, sure, Google is reusing the Google Workspace identifier for different workspaces, which could be used to impersonate a user; but if you own the domain, you can also receive email as that user and reset the account that way."

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#296

Post by nodamage »

radlad wrote: post #295
nodamage wrote: post #291

Earlier quoted context omitted.

> In the case of Google OAuth, it's possible to forego this in order to allow any Google user from any Google workspace to login to your application. There are plenty of use cases where this is appropriate. If you wanted to allow users to login to Hacker News with their Google accounts you would use this option because you do not care what workspace they belong to. > Some applications (e.g. Tailscale) take advantage…

> This is a misuse of the public Google OAuth API. Your first link clearly states: "A public application allows access to users outside of your organization (@your-organization.com). Access can be from consumer accounts, like @gmail.com, or other organizations, like @partner-organization.com." In other words it is intended for scenarios where you want to allow access to users outside your workspace. > According to yo…

I suppose this comes down to the interpretation of the documentation. Note that it only says "a workspace", not "a specific workspace" or "which workspace".

1) The "hd" claim tells you that the user is a member of a workspace. If the user is a member of a workspace it tells you the domain name of that workspace.

2) The "hd" claim tells you which specific workspace the user is a member of.

You are taking interpretation (2) whereas I am taking interpretation (1). I believe interpretation (1) is correct given the next sentence says you can use the "hd" claim to restrict access to only members of certain domains. If interpretation (2) was intended, they could have instead said you can use the "hd" claim to restrict access to only members of a certain workspace.

If Google is at fault for anything here it is for writing confusing documentation, however given the totality of the documentation where:

a) Google describes public applications as intended for logins from all Google accounts regardless of workspace, and

b) Google offers the internal application option for situations where you want to restrict logins to users of a specific workplace,

I'm going to stand by my conclusion that the real fault lies with service providers choosing the wrong integration option in the first place and then making invalid assumptions about what information the "hd" claim supplies in the public option.

Re: Google’s OAuth login doesn’t protect against purchasing a failed startup domain

#297

Post by nodamage »

radlad wrote: post #294
nodamage wrote: post #278

Earlier quoted context omitted.

> despite Google's docs stating that this is a valid use. :) I don't think Google's docs actually say this. I assume you are referring to the "hd" claim, but that only says: "The domain associated with the Google Workspace or Cloud organization of the user. Provided only if the user belongs to a Google Cloud organization. You must check this claim when restricting access to a resource to only members of certain domai…

>> I think certain service providers might have made the assumption that if a user belongs to a certain domain that also means they belong to a certain workspace, but that is clearly not a valid assumption. > If you need to validate that the ID token represents a Google Workspace or Cloud organization account, you can check the `hd` claim, which indicates the hosted domain of the user. This must be used when restrict…

Your quote does not actually contradict my original statement, full reply here: https://news.ycombinator.com/item?id=42743263
Post reply on HN