Comment by stackghost | Hacker News Reader

Comment by stackghost | Hacker News Reader

Parent Full thread

>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 therefore the same people as far as they're concerned and is asserting that to other companies.

Yep I understand the mechanism by which this gets abused; I think we just disagree on the implications. I don't work for Google but it seems from the outside that they're treating the OIDC subject claim as referencing the domain attached to the workspace account, or something similar. I've seen implementations where the `sub` claim is more granular, so to me that indicates the field is underspecified.

Given all that, I suppose TFAuthor's proposed solution is a good way forward.

I still think classifying this as an OAuth vulnerability isn't correct.

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 and internal applications" here: https://support.google.com/cloud/answer/6158849?hl=en#zippy=...

Some applications (e.g. Tailscale) take advantage of the public Google OAuth API to provide private internal corporate accounts. A common misconfiguration here is to use the domain portion of the "email" attribute - this can be spoofed by Google Workspace admins. That's not what's happening here.

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. This field cannot be overridden by Google Workspace admins. The trust breaks down when the domain changes hands, a new Google Workspace account is opened, but the old "hd" value is reused.

You can read more about "hd" here: https://developers.google.com/identity/openid-connect/openid... (find the table and read the descriptions for both "email" and "hd".)

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 (be very careful you mark it internal!) A new domain owner would not be able to retrieve the secret key you previously generated.

To clarify, any multi-tenant app that has a Google login button that "just works" without you having to set up your own OAuth client creds is using the "public" app option. Effectively the OAuth client side doesn't care whether you use a public Gmail account or enterprise Workspaces account to login.

However, on the Workspace Admin side you can set policies as to whether the org accounts can login to arbitrary public apps by default, or set up an app allowlist, etc. It's definitely a best practice not to let your users login to arbitrary apps, even if it's only for the profile data and not other API scopes.

If you do login to a public app with an org account, how that app decides to group/authorize users from (what it perceived as) the same org/domain could be a sensitive procedure with opportunity for exploit, and it seems like maybe Google should offer a more reliable unique org id claim.

If you are making your own internal app then client is going to be internal only by default. Note this is managed in a GCP project. If you're using Workspace and GCP then you may want to use GCP services with built-in Google auth like Cloud Functions, App Engine, Identity Aware Proxy, etc.

Yea "hd" doesn't work here.

Users can make google accounts with corporate domains but without gsuite hosting attached. The same concern applies to just @gmail.com addys. Google has gotten big on nuking inactive accounts now, what stops similar openings where a person's inactive account gets recreated by an attacker and waltz his way into SSO systems? There's some corporate systems (usually benefits) that allow personal emails attached to the same account as work emails for example.

I imagine the fact the author is writing that Google reopened the bug and is issuing a bounty means there are Google engineers more than aware of the issue rather than trying to argue what Google does and does not intend.

Once a Gmail account is deleted, it can't be recreated by anyone, including the original owner.

> 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.

Saving a click: "hd" means "hosted domain"

hd — 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 domains. The absence of this claim indicates that the account does not belong to a Google hosted domain

I can see value to that being a human readable string, and can see the value of "example.com" being able to be used to SSO for employees of both Example Inc. 1.0, and Example LLC 2.0.

That said, does seem an "hduuid" could be available for those who care, but mysteriously don't care enough to cancel their other SaaS relationships that use OIDC or SAML SSO.

> 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.

> 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."

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.

Reply on news.ycombinator.com