It’s insane and inscrutable.
I previously worked at the company that first created this gem. It was not written based off actually reading the spec. It was based off a loose examination of what other legitimate docs in the wild looked like, and built to parse those.
Which of course meant that early on it was vulnerable to everything since it was built to fit positive results and not negative ones. This isn’t even the first XML signature issue: early released versions didn’t even bother to check that the part being used was the part that was signed. If any part of the doc was signed and valid it was good to go.
Fun times.
Standards based on ASN.1 get a lot of hate (X.509 etc.) but I'd rather work with that than XML.
I am very confused by people who have emotional reactions to technologies. XML has a number of capabilities that are very difficult to represent in other documents without creating an unreadable mess. XML is more than just the worst SOAP api you've used.
Given the phrasing ("simplicity-hating architecture astronauts"), I suspect they're having an emotional reaction to a colleague who, at some point, advocated for their team's use of XML. Which I honestly think is slightly justified if their colleague's advocacy was thoughtless or otherwise unreasonable. Maybe JSON would actually work better for what they were doing. Of course, that said, I also say it's "slightly" justified because good ol' XML did nothing wrong.
Xml is a hierarchical days structure that has less data hinting to parsers /serializes than json.
Please don't say namespaces. Broke xpath and other parsing techs. Attrs vs tags? Cdata? Any one remember ibm web services being all cdata tags?
Using XML as an interchange format for things intended to be read by a machine is not so great. Don’t use it where you actually want something more like protobuf.
If XML was removed, these specs wouldn't have been much better. The motivation of the companies sponsoring specs was to build something that sold more enterprise middleware and identity servers. This was never going to be attractive to the individuals working with IETF, or the people working on web standards who'd create WHATWG (I know SAML isn't their domain.)
Many readers here also won't be aware of how web services, SOAP, and XML were the AI hype of the time. These were getting pushed into every kind of solution. At the same time, the alternative options for document and serialization formats weren't ubiquitous, so having XML everywhere was somewhat pragmatic for the average developer. I can't imagine ASP (or early-.NET) developers trying to deal with ASN.1.
The sad thing is that XML was meant as a simplification over full SGML for delivery of markup on the web. Specifically, XML is always fully tagged (doesn't make use of tag inference), and does neither have empty ("void") elements nor short forms for attributes such as in <option selected>. Thus XML never needs markup declarations for special per-element or per-attribute parsing rules. This was done to facilitate newer vocabularies next to HTML like SVG and MathML.
But soon enough, folks took the XML specification as an invitation for complexity and a self-serving spec circus: namespaces, XInclude (as a bogus replacement for entity expansion), XQuery, XSLT, XML Schema as a super-verbose replacement for DTDs using XML itself, etc. XHTML 2 was the largest failure and turning point, introducing not just a new vocabulary, but trying to reinvent how browsers work in a design-by-comittee fashion. It could be said that XHTML took W3C down along with it.
For message payloads in large and long-term multi-party projects (governments, finance/payments, healthcare, etc.), I'm however not sure the alternatives (JSON-over-HTTP and the idiotic quasi-religious apeal to misunderstood "REST" semantics) is really helping. XML Schema, while in part overkill and unused (substitution groups), certainly has facilitated separating service interface from service implementation, multiple generations and multiple implementations, test cases bases, and other long-term maintenance goals.
But I can't help noticing that Json is gaining more and more XML-like functionality through things like schemas and JsonPath, as people slowly realise why XML had those functions they're now having to replace. I'm a long way from convinced that all the engineering effort to switch was actually beneficial.
Yes, it's a badly named language. It has nothing to do with markup. As always, intentions don't matter at all, and it's the best tool we have for certain types of structures.
There wasn't a two-legged oauth gem at the time so I remember writing one and being blowing away at how much I actually understood the OAuth 1.0 2-legged spec.
In recent years IETF has given us SCIM (which is sort of like "offline SAML") which is 3 RFCs (goals, schemas, http stuff), and of course JWT is actually part of a series of like 9 RFCs (including JWT, of course, but also JWK, JWS, JWE, JWA, ...).
I think there's this phenomenon where people who are like "dude, nobody cares, just do the dumbest possible thing we can get away with" aren't the people who decide to get involved in writing security specs.
If you are talking about SCIM (System for Cross Domain Identity Management) then it’s very different from what SAML is. SCIM Is used for user provisioning where as SAML is used for SSO.
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
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.
Great analysis and thanks for sharing!
Most universities are still using Shibboleth. And probably will be forever. I think Shibboleth influenced SAML, probably to it's detriment.
Shibboleth has officially supported Plugins for OIDC for some time now.
As others said, Shiboleth is still rather pupular at Universities and higher Education, OIDC will have a hard time to set foot there without the OpenID Connect Federation Draft beeing finished and then Implemented by the different Metadata Federation that exist (most National Research Networks manage one)
I'd love to add FastFed support for OIDC and be done with it but SAML still rules the world.
Get used to disappointment.
Worse this is done at an element level not a document level as noted in the linked article.
Really, it’s not that simple. It typically requires a while xml library for dealing with it that is error prone. Check the number of errors and cves for libxmlsec for example. Or even the versions in C# or Java.
Then the incredibly stupid need to modify the signed document to insert the signature online so verifying it requires a full blown parser among other things
Whether they copied those algorithms from Russian ones, I don't know, never researched that.
https://coding.abel.nu/2016/03/vulnerability-in-net-signedxm...
I've seen invalid schemas/signatures where Id was just defined as string in the schema (fails when verifying using libxml/xmlsec for example)
I mean at some point you do have to understand the difference between xml and a specific schema of it and how its used in SAML, its not like xml elements are required to have a unique id attribute.
This isn't something you would call directly anyway unless you were writing your own SAML client, which isn't that hard but there are existing ones, here is a simple one that works well:
Some major problems with SAML are 1) the user’s browser acts as a MITM between the SP and IdP on all requests (vector for this attack), and 2) it requires the IdP and SP to maintain their own certs, which is fine in theory, but humans at big corps are lazy, and the complexity causes people to be lax on security.
This is exactly how OIDC implicit flow works. The basic difference is using JWT instead of signed XML otherwise it's nearly identical, I mean public/private key signing is the basis for JWT and XML sig.
SAML also supports artifact binding which would use a back channel similar to other ODIC flows, but I haven't seen it used much because its make things more complicated and requires the SP to be able to communicate with the IdP.
> Why are we making chandeliers out of swords of Damocles?
Amazing description of proliferating footguns.
in the case of XML signature verification they probably should return a list of (XMLElement, Path) tuples. so the actual XMLElement that was signed and verified by the API and a path to the element in the document. having APIs that return IDs and then make assumptions that the signature verification code and the consumer code is going to perform resolution the same way is dangerous. even returning the path is a potential footgun but I assume consumers of an XMLSignature need to be able to check that elements appear in certain places in the document. i guess also DOM model APIs are probably implicitly returning a path if they support navigating by `getParentElement()`.
Where else can one find such writing about security issues ?
Good suggestions from the article: work around it. The non-technical folks may force you to implement it in your system. Doesn't mean you have to leave your systems vulnerable.
I wish, but I'm pretty sure that it's still used in EBICS (latest version of the standard here https://www.ebics.org/securedl/sdl-eyJ0eXAiOiJKV1QiLCJhbGciO...), which is even scarier than SAML.
This stopped being true in 2005, see RFC 4050.
Pretty good advice. I believe it should be the default. The situations that require permissiveness should be exceptions and treated with a high degree of scrutiny.
