Comment by bawolff
Comment by bawolff a day ago
SAML has to be one of the worst security specs ever
Comment by bawolff a day ago
SAML has to be one of the worst security specs ever
Two things
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.
XML signatures in SAML suck so much they deserve to be your point one. For functionality at least it's possible to just poke around and see what works with whatever party your connecting, but debugging broken signing? With XML signatures it is possible to have it all working with one provider (perhaps a Windows machine running ADFS) and then be unable to verify the signatures from another, and you'll never know where the fault lies.
At least with modern stuff like JWT's the ways to encrypt and sign are well-understood.
It also supports putting keyinfo into the document as well and validates it by default unless you really know to go out of your way to disable it.
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.
> Comments arent signed but change meaning of document
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
https://duo.com/blog/duo-finds-saml-vulnerabilities-affectin... has the full details.
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.
> 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?
It is drastically harder to understand than OIDC, in large part due to XML signatures, which are a demented format, mostly for the reasons stated in this blog post (but also for some reasons it shares with JWT, and also for some sui generis reasons having to do with how complicated xmldsig is and how few implementations there are of it). You really couldn't find a worse format to do cryptography with than XML.
It's not just shitty implementations here. The designers of SAML and XMLDSig cannot just blame the developers for implementing their "perfect" spec incorrectly.
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.
> It's not just shitty implementations here
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.
It’s also a nested meta protocol with an extensible markup language (XML) used to express extensible fields but using SAML encoding for them instead of just XML. It’s the inner-platform effect, which is common in over engineered monstrosities like SAML.
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.