My favourite SAML horror story, is that it used to be, that by default the main c implementation of xmlsig would not just check the sig with the public key specified but would also:
- check it against an hmac using a password specified in the attacker controlled document.
- check the signature using web pki (so the attacker could sign the saml document with their TLS key for their own personal domain and it would always be considered valid)
I honestly dont know how sites with saml arent getting hacked all the time. The only thing worse than the absolute terrible standards are the absolute terrible implementations.
I saw multiple implementations that looked for a signature, verified it, then just trusted the document as a whole rather than only the part that was signed. So as long as you had any signed SAML doc, you could provide an attention of your choosing and just bundle the signed one somewhere arbitrary inside of it.
It’s also enormous, I assume from the attempt to have nominally composable parts that could be reused for other flows.
It’s three entire specs bundled as one. One for the XML components, another for the documents you build from them, and another for the authentication flows built on top.
It is truly surprising how large the specs for each of these ecosystems are: PKI, Kerberos, TLS, OAuth, SAML, etc. They are gargantuan, especially when you include essential dependencies like DER codecs and ASN.1 compilers (PKI, Kerberos) or XML (SAML).
“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”
The problem with this is the assumption that there's a simpler way to do all of this, and if only we could stop looking for large and complex solutions we could just land on the simple ones.
I listed a number of solutions, all built by different people, at different times, in different orgs, and some of those solutions (OAuth, SASL) being much more organic in how they evolved, and yet all are ultimately large and complex.
I think that hints at the problem space being... large and complex and requiring large and complex solutions.
What we _can_ do is avoid adding complexity unnecessarily, but what looks like a simplification today (e.g., picking the best current encoding system) might look like a terrible mistake in twenty years.
bawolff · · focus · HN ↗
- check it against an hmac using a password specified in the attacker controlled document.
- check the signature using web pki (so the attacker could sign the saml document with their TLS key for their own personal domain and it would always be considered valid)
I honestly dont know how sites with saml arent getting hacked all the time. The only thing worse than the absolute terrible standards are the absolute terrible implementations.
stouset · · focus · HN ↗
tptacek · · focus · HN ↗
stouset · · focus · HN ↗
It’s three entire specs bundled as one. One for the XML components, another for the documents you build from them, and another for the authentication flows built on top.
cryptonector · · focus · HN ↗
arethuza · · focus · HN ↗
C. A. R. Hoare
cryptonector · · focus · HN ↗
I listed a number of solutions, all built by different people, at different times, in different orgs, and some of those solutions (OAuth, SASL) being much more organic in how they evolved, and yet all are ultimately large and complex.
I think that hints at the problem space being... large and complex and requiring large and complex solutions.
What we _can_ do is avoid adding complexity unnecessarily, but what looks like a simplification today (e.g., picking the best current encoding system) might look like a terrible mistake in twenty years.