nodamage

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.

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

> If I log in using Google oauth, you already know the Google account is active.

You know there is an active Google account but (for the public OAuth integration option) it can be any Google account from any workspace, or no workspace.

"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." [1]

> Yes, but that's an additional check, separate from the one you suggested would eliminate the issue:

If you set up an internal OAuth integration option no separate check is necessary, it will actually restrict access to users of your workspace.

"An internal application will only allow access to users from your organization (@your-organization.com)." [1]

You can use the SAML integration option as well. [2]

[1] https://support.google.com/cloud/answer/6158849?hl=en#zippy=...

[2] https://support.google.com/a/answer/6357481

Assuming the above is correct, if you decide to connect Google SSO to your application using option (3), then it is not a vulnerability that a Google account from a different workspace can connect to your application, because the entire point of option (3) is that users with any Google account (regardless of workspace) can connect to your application.

If you intended to restrict your application to users of your own workspace then you should have used option (1) or (2).

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

It does not say you can use this claim to restrict access to members of a certain workspace, only for a certain domain.

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.

I think that Google's public OAuth integration is only intended for use in situations where you want to allow logins from any Google account, regardless of workspace membership, and if you want to restrict logins to Google accounts belonging to a specific workspace, you are supposed to use one of the other integrations.

Given all that, I still do not think this is a problem with Google's OAuth implementation. Instead it is a problem with service providers who have incorrectly used the wrong type of Google SSO integration. Or in the case of service providers that offer multiple Google SSO integration options (like Slack), it is a problem with the company for selecting the wrong one.

Google's public OAuth is intended for situations where you want to allow anyone with a Google account to login to your application, regardless of workspace. Given that, it is not a Google OAuth vulnerability that a user can login to your application using a Google account from a different workspace.

If you want to integrate Google SSO into your application and restrict logins to a specific workspace, there are other options you can use that will actually check if the user belongs to that workspace (SAML or internal OAuth).

To the extent that service providers are using Google's public OAuth and then trying to read the domain name out of the returned ID token in order to restrict logins a specific Google workspace, they are using Google's public OAuth instance for a situation it was not intended for because domain names do not map 1:1 to workspaces. However that is a vulnerability on the service provider's side, not Google's.

To the extent that a service provider offers Google SSO integration via Google's public OAuth but also via workspace restricted options, if a company selects the former instead of the latter then the responsibility for the vulnerability is on the company's side. (Slack, for example, offers both because there are some Slack groups where allowing access from any Google account makes sense, and other groups where you would want to restrict access to Google accounts from a specific workspace.)

Only if you use the Google public OAuth integration. If you instead use the SAML integration with Slack as described in the link above you don’t have this problem.

If I'm understanding your comment correctly there are three different ways to connect Google SSO to your application:

1. SAML. This avoids the issue because certificates need to be exchanged between Google and your application, but an attacker that recreates a duplicate workspace using your domain won't have access to those certificates. Only users from your workspace will be allowed to login.

2. A custom Google OIDC IdP configured for internal access only. This also avoids the issue because a secret key is required to set this up and the attacker won't have access to that key. Again, only users from your workspace will be allowed to login.

3. The public Google OAuth API which will allow any Google user from any workspace (or non-workspace users) to login to your application.

Is this correct?

> And people are telling you that this is not possible with the Google public OAuth API.

Yes I understand, however it is possible to integrate Slack and Google SSO in such a way that it checks that the user belongs to the correct workspace, correct? Either via the SAML integration (https://support.google.com/a/answer/6357481) or an internal Google OAuth integration? The purpose of the public Google OAuth API as opposed to the previous two options is to allow logins from non-workspace or cross-workspace Google accounts, correct?

What I'm suggesting is if you were able to pre-configure Slack to only allow logins for valid users from Google Workspace X, then even if someone creates a new workspace Y with the same domain, Slack would still be checking against workspace X. (And similar for non-Google based identity providers.)

I don't think so, but please go ahead and clarify if that is the case.

Yes. If you've set up your Slack so each login checks against the identity provider to ensure an active user is logging in, that would resolve the issue, no?

Even if you take over company.com's domain you can't reconfigure company.com's Slack to point to a new identity provider?

I'm not talking about checking against the domain, but checking against a directory of active users.

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.

If, when you logged into Slack via Google Oauth with the email address user@company.com, Slack checked with company.com whether user@company.com was a valid user that should be allowed to login, then this problem would be avoided entirely because the defunct company would no longer report any valid users.

This would also avoid further problems with attackers being able to login with unattended email addresses like support@company.com, as was discussed here: https://news.ycombinator.com/item?id=41818459 (There's a lot of discussion below about whether the "sub" claim is stable or not but it's a red herring because of this IMO, also the proposed fix in the article wouldn't address it either.)

Over-moderation is mostly to blame for this, IMO. Too many questions get closed as a duplicate of an existing question without the mod realizing that the answer to the existing question is obsolete and no longer useful.

> I worry about things like fetching new data into a page not altering the screen reader user in the same way as refreshing a page completely would.

Isn't this more of a general browser question that would apply to any website that uses Javascript to load page elements?

How would using HTMX (as opposed to any other library, or plain old Javascript) affect the answer to the question?

As far as I can tell the two main criticisms in the video are that:

1. The Redis API requires the developer to use different commands to retrieve/manipulate data depending on the type of data being stored. To retrieve a string you use GET, but if you want to retrieve a list it's LRANGE, for a set it's SMEMBERS, for a hash it's HGETALL. (As opposed to an API design which would allow you to call GET on all of the different data types and have it return the right thing.)

2. The lack of a predefined schema means you can overwrite values with different types. So you can create a list named "foo" and then overwrite it with a string named "foo" and then overwrite that with a hash named "foo" and Redis will happily do it, meaning the developer needs to keep track on their end what actual type any given key is holding onto.

To me these criticisms come across as essentially saying "Redis doesn't behave like a RDBMS" to which I suppose antirez's point is "well, yeah, it's not supposed to".

If you never actually took the steps to cancel your contract won't they be able to prove your debt via the existence of a non-cancelled contract?

Just to be clear, the Justice Department has filed a lawsuit but they have not actually won it. Until a judge or jury rules in their favor (and appeals are exhausted) you cannot cite the mere existence of a lawsuit as proof of anything. Keep in mind that Epic also filed a lawsuit claiming Apple was a monopoly but could not prove it in court.

Listing eBay and NYT seems pretty misleading when it's actually eBay Motors and NYT Games and not their primary apps.

I can't tell if the same applies to Square or American Airlines but I would not be surprised.

> With web apps, it's easy – just scan HTML, deduce what framework is used, and add it to your showcase list. With Flutter mobile/desktop apps it's not possible.

Seems like it is: https://play.google.com/store/apps/details?id=com.fluttersha...

I think the most likely threat in this case is with ex-employees. If Bob has access to bob@example.com and creates an Apple account with it, then subsequently gets fired from example.com, they might delete his email address but his Apple account will still allow him to login to services using Sign in with Apple. (Because Apple only checks ownership of the email address when the Apple account is being created.)

Google accounts have the exact same issue so I don't understand the distinction made by the OP though.

Apparently so do Google and Github according to the other comments in this thread. Seems like a potential design flaw in these SSO implementations.

Don't get me wrong, Zendesk definitely has their own separate problem: you should not be able to CC yourself onto an existing support ticket by emailing a guessable ticket ID.

But simultaneously you should not be able to get into a company Slack by simply having an account with a @company.com email address created by a third-party SSO provider.

In other words, even in Zendesk fixed their problem, Slack would still have a problem on their end.

In case it's not clear these are the two separate vulnerabilities:

1. Zendesk allows you to add a CC to any existing support ticket by sending a (spoofed) reply from the original requestor's email address to that ticket's Reply-To address and including a CC in the email.

In some circumstances the Reply-To address is based on an auto-incrementing integer so it can be guessed. (Although this may not alway be the case: my email archives show some emails from Zendesk using the integer and other emails using a random alphanumeric string. It seems to vary by company so it might be some sort of configuration setting?)

2. Slack allows third-party domain-wide logins via Sign in with Apple without additional verification that the email belongs to a real person. Here the author of the article pretends to be support@company.com to Slack and Slack lets them into the company.com channel, despite the fact that support@company.com does not actually represent a real user and is only intended to be a receiving email address that forwards into Zendesk. (This sounds more like a configuration problem than anything else though.)

The email sender needs to be spoofed in order to add the CC.

1. Apple sends a legitimate email with a verification code from appleid@id.apple.com to support@company.com, creating a ticket in Zendesk.

2. The attacker then sends an email to support-$ticket-ID@company.com from appleid@id.apple.com (spoofed), attaching their own email address in the CC field.

3. Since the attacker is now CC'ed they can read the entire history of the ticket including the legitimate email Apple sent in (1) containing the verification code.

4. Now that the attacker has verified ownership of the Apple ID with the email address support@company.com they can use that Apple ID to login to any service that grants domain-based access via Sign in With Apple, such as Slack.

> EDIT: they absolutley should not use an autoincrementing int as a "support-chain token" though, that's a workaround they could easily do.

I checked my email archives and some (but not all) of the emails I've received from Zendesk have arbitrary alphanumeric ids in the Reply-To header instead of integers. Seems to depend on the company, perhaps this is a configuration issue?

The Slack takeover exploit is a problem on Slack's end (and sounds more like a configuration issue than a bug) so Zendesk would not be responsible for that anyway though.

Wait, does this apply to software?

Probably because the original tax rulings were made prior to the existence of the EU. As to why it was never "fixed", I have no idea.