Signed xml alone is a wildly confusing idea, as the signatures get embedded as elements in the document being signed. There’s a wild set of rules on how to make xml canonical, sign, add the signature, etc. It’s nontrivial.
I love this quote from the blog:
> Why are we making chandeliers out of swords of Damocles?
Amazing description of proliferating footguns.
Recent RubySaml contributor here. The problem in this issue is not only RubySaml, but actually much older code in a module called XmlSecurity.
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.
I know very little about XML and SAML, but from what little I do know it shocks me that it's still the de-facto standard for SSO.
Great analysis and thanks for sharing!
Microsoft's SignedXml implementation in the .Net framework fixed this 8 years ago so long as you are correctly using the GetIdElement which makes sure there are no duplicates.
https://coding.abel.nu/2016/03/vulnerability-in-net-signedxm...
i think the problem is signature verification APIs should return the signed data or an error and then the consumer should use the signed data from the API and not any other data. then there is no confusion over what was signed or not.
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()`.
This article actually reads like a dev who understands the problem and has an opinion.
Where else can one find such writing about security issues ?
Businesses that want to integrate with larger SaaS providers and enterprises are often compelled to implement SAML. I used to fight tooth and nail to avoid it over issues with the SAML spec but... business is business.
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.
Unfortunately XML signatures are also widely used in Polish government APIs which citizens/companies are required to use :(
SAML has to be one of the worst security specs ever
"Nobody cares about XML Signatures anymore, except in the context of SAML"
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.
> All an XML signature does is let you cryptographically sign an XML document. Same thing as what JWTs do with alg: "RS256" (no ES256, because remember: the year is 2000).
This stopped being true in 2005, see RFC 4050.
> Ignore Postel
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.
SAML is absolutely insane. It’s three separate specs: one that defines what every XML element means semantically, one that defines multiple document models that you might want to combine those to use, and one that talks about network protocols you might want to use those documents in.
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.