Comment by arpinum
2 hours ago
SAML is even worse than the article describes, problems like needing to check what the signature actually signs. But I'm optimistic about the future, instead of relying on libraries that do a lot, such as general xml parsing, we can support a subset of SAML and only the dialects of the top ~10 providers. Extreme niche providers can be added ad-hoc and only if the deal size makes it worthwhile.
> … needing to check what the signature actually signs.
I mean … how else would you check a signature? You have to have the data to validate the signature.
It’s XML, so the signature inside the document somewhere and signs some other part of the document by reference.
You would be shocked (or, if you’re in the security space at all, not even remotely shocked) to learn that a comical number of SAML implementations verified the signature and then just treated the whole doc as if it was trusted, even if the signed part had nothing to do with the document as a whole.
Normally you sign the whole dicument.
In SAML you sign a (potentially attacker controlled) subset after normalization. So a lot of saml bugs come down to the attacker adding things that aren't covered by the signature. Sometimes this means appending or prepending stuff, but my favourite is adding comments which can alter the interpretation of the xml document (as it splits text nodes) but doesn't alter the signature.
And this doesn't even get into "which normalization approach!" or "what gets signed (or not)!"
It's an absolute dumpster fire.
In a JWT this is simple, the signature checks the entire sig and data sections. In XML signatures it checks whatever it says it checks, a list of URIs, which may also be transformed.
So it is possible to have an XML signature that points to an element that does not include some important piece of data.
Or maybe it does include the important info at sign time, but the attacker adds additional info that confuses the program parsing the document.