Most active commenters
  • tsimionescu(4)

←back to thread

Sign in as anyone: Bypassing SAML SSO authentication with parser differentials

(github.blog)
312 points campuscodi | 14 comments | 15 Mar 25 19:06 UTC | HN request time: 1.904s | source | bottom
Show context
asmor ◴[15 Mar 25 20:50 UTC] No.43375068[source]▶
GitHub's SAML implementation is useless. The idea is that you can bring your own account into an enterprise, and that sort of works on the site itself, but it does not prevent apps where you log in with GitHub from reading your organization membership once you have authorized an app on the organization level (and if you didn't, it hides the membership from oauth tokens, so it has this capability!).

A SAML session is only required if said app fetches data via a token obtained from that user - and in my glance around, this was almost never the case - SAST tools almost always use app instance tokens and are happy to show anyone with a GitHub account in your organization your code. Tailscale fixed this when I pointed it out, Sonarcloud told me to please don't tell anyone and GitHub took a few weeks to say this is totally expected behavior - when no vendor I told did, and their docs contradicted them.

I swear, reporting security bugs is a thankless endeavor, even if you just randomly stumble over them. I couldn't imagine doing this as a job.

replies(6): >>43375206 #>>43375506 #>>43375716 #>>43375938 #>>43377351 #>>43377358 #
eCa ◴[15 Mar 25 22:19 UTC] No.43375506[source]▶
> The idea is that you can bring your own account into an enterprise

The issues goes beyond authorization. I’ve had Github randomly once in a blue use my personal email address as the default when merging a work PR. If anyone asks, I advice against mixing personal and professional stuff in the same Github account (or anywhere).

replies(6): >>43375751 #>>43375789 #>>43375867 #>>43378299 #>>43378875 #>>43391280 #
l72 ◴[15 Mar 25 23:13 UTC] No.43375789[source]▶
My company does not allow any employees to use their personal GitHub for work (or Facebook, instagram, or anything else) after running into issue when employees leave.
replies(1): >>43375911 #
booi ◴[15 Mar 25 23:38 UTC] No.43375911[source]▶
Wouldn’t you just remove them from the org?
replies(1): >>43376044 #
onionisafruit ◴[16 Mar 25 00:11 UTC] No.43376044[source]▶
They may decide to change their github login to <company_name>LIES, and suddenly that’s all over your old PRs and Issues. Including in public repos where customers go looking for help.
replies(1): >>43376296 #
TheDong ◴[16 Mar 25 01:20 UTC] No.43376296[source]▶
That's even more true with a dedicated work github account than a mixed personal/work one; either way they can still login and edit the account name even if removed from the company org, and if it's not shared it doesn't burn their personal account too... right?

Is this speaking from experience?

replies(2): >>43376458 #>>43376464 #
1. wlesieutre ◴[16 Mar 25 02:02 UTC] No.43376464[source]▶
With a dedicated work account the organization can always take over the account (via reset email if need be, since they own your work email account) and do whatever they want with it
replies(1): >>43376802 #
2. rendaw ◴[16 Mar 25 03:39 UTC] No.43376802[source]▶
A dedicated work account _where you use your work email address_... that was the missing part throughout this thread.

But then if you do that you also lose all your open source work history, which is important from a hiring/resume perspective.

replies(3): >>43377011 #>>43377076 #>>43379051 #
3. cdogl ◴[16 Mar 25 04:56 UTC] No.43377011[source]▶
One option for those so inclined is to cryptographically sign commits with a key that lists both work and personal email address (assuming your enterprise’s policy allows it). The employer retains control but you have a claim to credit for your work.
replies(1): >>43377181 #
4. connicpu ◴[16 Mar 25 05:26 UTC] No.43377076[source]▶
If a spiteful ex-employer wants to scrub ex-employee authorship from the entire commit history in their public repos when someone leaves I don't think there's anything you could do to stop that either way, though it seems like it would be more trouble than it's worth and likely wouldn't scale. If they don't do that, assuming your old company email address still has your name in it I don't see why you'd lose credit for the work you did.
5. tsimionescu ◴[16 Mar 25 06:04 UTC] No.43377181{3}[source]▶
If we're discussing companies willing to go to lengths to scrub you from their GitHub history, they can still replace all commits you've signed with new commits. You likely have no legal rights to that work, and git does allow you to rewrite history arbitrarily.
replies(2): >>43377693 #>>43378029 #
6. shiomiru ◴[16 Mar 25 08:49 UTC] No.43377693{4}[source]▶
> git does allow you to rewrite history arbitrarily.

Technically yes, but the price is too great - everybody who has cloned the repos will now have to nuke their local copies too.

replies(1): >>43379666 #
7. withinboredom ◴[16 Mar 25 10:41 UTC] No.43378029{4}[source]▶
It depends on the jurisdiction. In the US, copyright assignment is usually permanent. In the EU and Canada, you can claw back your rights to a degree and even revoke the usage altogether, if you manage to claw it back because they did "evil" things with it (moral rights).

In some cases (even in the US), if the employer does something that would be considered a "breach of contract", you can force them to remove all your code as well.

So, it would not be in the company's best interest to scrub their git history.

replies(1): >>43379657 #
8. OJFord ◴[16 Mar 25 13:43 UTC] No.43379051[source]▶
And you could still just change it right, as long as you did so before the employer revoked your access via the work email address.
9. tsimionescu ◴[16 Mar 25 15:09 UTC] No.43379657{5}[source]▶
I think even in the EU and Canada, you don't have any copyright interest in work your perform as part of your employment. The copyright on the work you produce for your employer is entirely theirs, from the moment it is created.

Now, if you're a contractor performing work for a company, this may be quite different. But as an employee, I don't think you have any claim of authorship to the code you right as part of your job.

replies(1): >>43387292 #
10. tsimionescu ◴[16 Mar 25 15:11 UTC] No.43379666{5}[source]▶
Sure, but the same is true for unsigned commits as well, isn't it? Or can you modify the commit metadata without changing the commit hash in those cases?
replies(1): >>43381338 #
11. shiomiru ◴[16 Mar 25 19:08 UTC] No.43381338{6}[source]▶
> Sure, but the same is true for unsigned commits as well, isn't it?

Yes, I think so. As I understand, GP's idea was to sign your commits proactively.

replies(1): >>43381713 #
12. tsimionescu ◴[16 Mar 25 19:57 UTC] No.43381713{7}[source]▶
My question was, is signing the commits really useful? Isn't it just as hard or easy to scrub you from the repo history regardless of whether the commits are signed or not?
13. withinboredom ◴[17 Mar 25 11:22 UTC] No.43387292{6}[source]▶
Look up "moral rights." You have some ability to revoke the usage of your work if it violates moral standards.
replies(1): >>43391342 #
14. TheNewsIsHere ◴[17 Mar 25 18:25 UTC] No.43391342{7}[source]▶
Some countries allow authors to transfer/assign or waive asserting their moral rights. Typically (and sensibly) this must be in writing.