←back to thread

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

(github.blog)
312 points campuscodi | 10 comments | 15 Mar 25 19:06 UTC | HN request time: 0.935s | 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 #
1. weard_beard ◴[15 Mar 25 21:14 UTC] No.43375206[source]▶
This is the operating procedure at every conceivable level. You would not believe how difficult it is to convince young developers raised on Javascript that client side validation is not enough, much less the business owners setting out functional requirements and budgets.
replies(2): >>43375468 #>>43375803 #
2. weard_beard ◴[15 Mar 25 22:12 UTC] No.43375470[source]▶
They'd be fired if they spent a penny more fixing it.
3. UltraSane ◴[15 Mar 25 22:32 UTC] No.43375586[source]▶
Musk should be fired. He has irreversibly destroyed the Tesla brand.
replies(1): >>43375633 #
4. woleium ◴[15 Mar 25 22:43 UTC] No.43375633{3}[source]▶
But has he realized yet?
replies(1): >>43375792 #
5. NewJazz ◴[15 Mar 25 23:14 UTC] No.43375792{4}[source]▶
I wouldn't be surprised if the recent stock downturn is mostly him illegally offloading shares without disclosing it.
6. cluckindan ◴[15 Mar 25 23:16 UTC] No.43375803[source]▶
”You would not believe how difficult it is to convince young developers raised on Javascript that client side validation is not enough”

At first read, I think you’re JSplaining, but I’m willing to give you the benefit of the doubt.

How difficult is it exactly? Can you provide examples, perhaps even of the particular difficulties? Are the difficulties on the side of the convincer or the convincee, or both?

replies(1): >>43375886 #
7. nextts ◴[15 Mar 25 23:34 UTC] No.43375886[source]▶
I think it is something they have to experience. Tell them if they are happy with it, give me a $10 bug bounty. Then go hack a deploy of their branch. Then tell em to keep the $10 but remember the lesson.
replies(1): >>43376277 #
8. fn-mote ◴[16 Mar 25 01:16 UTC] No.43376277{3}[source]▶
Wow. I would never guess it was so hard to convince someone of this.

“The code I write doesn’t have XSS or SQL injection vulnerabilities,” sure. At least those are plausible things to believe.

Client side validation?? How could anybody believe in that?

replies(2): >>43376606 #>>43398841 #
9. nine_k ◴[16 Mar 25 02:42 UTC] No.43376606{4}[source]▶
I convinced fellow engineers who were adamant that the code they had written was OK by writing actual exploits against their code. Twice. Worked both times, without betting on money.
10. wglb ◴[18 Mar 25 12:53 UTC] No.43398841{4}[source]▶
An axiom of secure programming is to never trust the client. You don't really know what the client is.

Often it takes several penetrations via compromised/replaced clients to get the message through.

Just look at all the discussions about why browser-based javascript encryption is problematic.