Why do you say that? I think it’s ugly, but it’s substantially simpler to understand than oidc. What parts of the spec (read: not just shitty implementations by developers) are bad?
I’m genuinely curious here, I’m not attempting to bait an argument.
I’m genuinely curious here, I’m not attempting to bait an argument.
Saml itself is sort of a kitchen sink. It includes everything you could possibly ever want, but nobody implements all of it so you need to figure out common subset, which defeats the point of a standard.
Second, XMLSignature sucks... like badly. Only part of the response is signed, but which part there is no standard on. It is way too complicated. Why have multiple overlapping signatures is crazy. Comments arent signed but change meaning of document. A billion signature types. Etc.
At least with modern stuff like JWT's the ways to encrypt and sign are well-understood.
Oh look, another signature issue…
https://github.com/advisories/GHSA-2xp3-57p7-qf4v
When googling for a SAML dependency, if a library doesn’t already have CVEs for this stuff, it’s likely never been tested.
Do you have an example of that assertion handy? The only comment-influences-execution behavior I'm aware of is in SQL[1], and I haven't ever seen any XML system (in any business domain) which does what you said
1: I mean, setting aside linter suppression, which pedantically does impact execution but I meant of the final software
But basically in some xml apis, a comment can split a single text node into two adjacent text nodes. Some implementations would only look at the first text node. The original xsignature spec (although i think this has been changed) said to remove all comments from doc before signing it, so the attacker can add arbitrary comments without messing up the signature.
Right, I believe you, but the original assertion was "change meaning of document" -- I can likely add arbitrary whitespace, too, under that same "tomato, tomahto" canonicalization path, but how do either of those two insertions benefit the attacker by changing the meaning of the document?
The blog post above details exactly why XMLDSig can only be implemented securely, if you explicitly make an effort to ignore the spec. When following the specification leads to insecure implementations it's the spec that's shitty, and the spec authors should carry the blame.
The Open ID spec isn't great either and has its own share of issues, but in most scenarios, it doesn't rely on signature validation. If you only use the authorization code flow, breaking the ID token signature becomes ineffective, since the attacker still needs a valid authorization code from the IdP for this attack. If you restrict your implementation to what is allowed in OAuth 2.1 [1] or follow OAuth Best Practices [2], you can implement Open ID Connect pretty safely, as they eliminate the implicit grant and introduce PKCE.
I sure wish the OpenID foundation would cut all the unnecessary bloat in their spec(namely the ID Token, Implicit and Hybrid Flow and unnecessarily client-side token validation rules) and leave it as just a simple extension to OAuth 2.1 that specifies a few extra parameters and a User Info Endpoint. But if we have to leave with this over-engineered spec, I can still trust that implementations of OIDC would fail less horribly than SAML.
I agree 100% the spec is shitty, but on top of it,some of the implementations are really weird beyond the spec. there was a prominent c library for it that (last i checked) in the default config added a custom hmac signature version where the hmac key is embedded in the attacker control document, and also hooked into the the system web pki, so if the provided key doesnt match, it will test if the doc was signed by a tls key from any website in the world.