from Hacker News

Ruby-SAML pwned by XML signature wrapping attacks

by ucarion on 9/18/24, 9:59 PM with 91 comments

  • by stouset on 9/18/24, 11:53 PM

    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.

  • by bfrog on 9/19/24, 12:54 AM

    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.

  • by quickgist on 9/19/24, 4:33 AM

    I love this quote from the blog:

    > Why are we making chandeliers out of swords of Damocles?

    Amazing description of proliferating footguns.

  • by dudeinjapan on 9/19/24, 1:18 AM

    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.

  • by caust1c on 9/18/24, 10:38 PM

    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!

  • by SigmundA on 9/18/24, 11:48 PM

    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...

  • by benmmurphy on 9/19/24, 10:09 AM

    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()`.

  • by lifeisstillgood on 9/19/24, 7:35 AM

    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 ?

  • by agentultra on 9/19/24, 1:36 PM

    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.

  • by zb3 on 9/19/24, 12:58 AM

    Unfortunately XML signatures are also widely used in Polish government APIs which citizens/companies are required to use :(

  • by bawolff on 9/18/24, 11:30 PM

    SAML has to be one of the worst security specs ever

  • by brohee on 9/19/24, 2:01 PM

    "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.

  • by layer8 on 9/19/24, 2:36 PM

    > 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.

  • by agentultra on 9/19/24, 1:32 PM

    > 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.