Y
HN Search
Hacker News Search
new
|
comments
|
top
|
jobs
nodamage
searching PlanetScale…
1.
▲
2.
▲
3.
▲
4.
▲
5.
▲
6.
▲
6 ms
·
31.
▲
by
nodamage
2y ago
> 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
32.
▲
by
nodamage
2y ago
> 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 workspac
33.
▲
by
nodamage
2y ago
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 po
34.
▲
by
nodamage
2y ago
> 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 G
35.
▲
by
nodamage
2y ago
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 yo
36.
▲
by
nodamage
2y ago
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.
37.
▲
by
nodamage
2y ago
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
38.
▲
by
nodamage
2y ago
> 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 workspa
39.
▲
by
nodamage
2y ago
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 wor
40.
▲
by
nodamage
2y ago
I don't think so, but please go ahead and clarify if that is the case.
41.
▲
by
nodamage
2y ago
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 co
42.
▲
by
nodamage
2y ago
I'm not talking about checking against the domain, but checking against a directory of active users.
43.
▲
by
nodamage
2y ago
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
44.
▲
by
nodamage
2y ago
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.
45.
▲
by
nodamage
2y ago
> 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
46.
▲
by
nodamage
2y ago
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
47.
▲
by
nodamage
2y ago
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?
48.
▲
by
nodamage
2y ago
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. K
49.
▲
by
nodamage
2y ago
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.
50.
▲
by
nodamage
2y ago
> 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/st
51.
▲
by
nodamage
2y ago
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 ac
52.
▲
by
nodamage
2y ago
Apparently so do Google and Github according to the other comments in this thread. Seems like a potential design flaw in these SSO implementations.
53.
▲
by
nodamage
2y ago
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 com
54.
▲
by
nodamage
2y ago
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 Rep
55.
▲
by
nodamage
2y ago
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 s
56.
▲
by
nodamage
2y ago
> 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 receive
57.
▲
by
nodamage
2y ago
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.
58.
▲
by
nodamage
2y ago
Wait, does this apply to software?
59.
▲
by
nodamage
2y ago
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.
60.
▲
by
nodamage
2y ago
An important point that seems to have been missed by most of the comments: the reason Apple lost this case is not because of the profit shifting scheme itself, but rather than they did not set up the scheme correctly: > ASI's 2014
More ›