29 ms·

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

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.

ucarion 2y ago
You'll be pleased to know that we're not making a ton of progress on the "split things over N docs" front. 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.
- victor106 2y ago
  > SCIM (which is sort of like "offline SAML") 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.
paradox460 2y ago
Hey a fellow ol alum. Boy I have dark memories of what that gem cost
- jrozner 2y ago
  Also an alum from WAY back (pre-A). One of the first things I did when I started was look at a different wrapping vuln.
userbinator 2y ago
In my experience, anything XML-related seems to be the product of simplicity-hating architecture astronauts with zero consideration for efficiency, possibly as a way of justifying their existence and continued employment. Standards based on ASN.1 get a lot of hate (X.509 etc.) but I'd rather work with that than XML.
- amluto 2y ago
  I find XML to be perfectly fine as a markup language. I once set up a system to generate logs as XML elements and display them prettily with XSLT. It was delightful! 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.
  - bawolff 2y ago
    XML isnt great for that, but the xml part is the least of the concerns. XSignature and SAML are insane specs, and would still be insane if the underlying presentation language wasnt xml (i mean, then you wouldnt be using xsignature, but if you made sone xsignature like thing for a different presentation language, it would still be crazy)
    - amluto 2y ago
      Signatures in XML are nuts. So is all the mess built around RPC in XML, although IMO that’s not as bad as signatures. But the problem with signatures has nothing to do with XML per se in my opinion. I could just as easily come up with a similarly poor signature scheme in HTML (snicker), nasty C structs with endian issues, MIME, or even plain English. Hah, someone should make a signature scheme meant to be verified by an LLM that parses it and calls out to a helper to do the actual math :) Seriously, though, signing XML well is easy. Take some XML, serialize it to bytes, sign with libsodium, and transport the bytes of XML and the bytes of signature. But do not get cute and transport the signed XML as a subtree in another XML document: the bytes must bytes until the signature is verified. You could maybe get away with sticking it in another document as CDATA [0], but base64 would be better, since you basically can’t screw it up. And it’s entirely possible to screw even this up JOSE-style if you lose track of what a “key” is. DO NOT have the signed (document, signature) tuple specify the signature algorithm or parameters. All of that is part of the public key, which the verifier (obviously) needs to acquire out of band. [0] Someone may pwn, or at least massively confuse, you if you do this. Imagine what happens if the inner and outer documents have different character encodings.
bradly 2y ago
I was jamming this gem rails back in 2009-2010 and will tell you we had no idea what we were doing on our side either. We were a couple a Rails devs at a tiny start up implement Qualcomm's SSO and tbh I'm surprised it actually worked. 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.
- runiq 2y ago
  In case there are other people like me who don't know what 'two-legged authentication' is: https://stackoverflow.com/a/2880692 https://stackoverflow.com/a/2880692

ucarion 2y ago

You'll be pleased to know that we're not making a ton of progress on the "split things over N docs" front. 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.

victor106 2y ago
> SCIM (which is sort of like "offline SAML") 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.

paradox460 2y ago

Hey a fellow ol alum. Boy I have dark memories of what that gem cost

jrozner 2y ago
Also an alum from WAY back (pre-A). One of the first things I did when I started was look at a different wrapping vuln.

userbinator 2y ago

In my experience, anything XML-related seems to be the product of simplicity-hating architecture astronauts with zero consideration for efficiency, possibly as a way of justifying their existence and continued employment. Standards based on ASN.1 get a lot of hate (X.509 etc.) but I'd rather work with that than XML.

amluto 2y ago
I find XML to be perfectly fine as a markup language. I once set up a system to generate logs as XML elements and display them prettily with XSLT. It was delightful! 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.
- bawolff 2y ago
  XML isnt great for that, but the xml part is the least of the concerns. XSignature and SAML are insane specs, and would still be insane if the underlying presentation language wasnt xml (i mean, then you wouldnt be using xsignature, but if you made sone xsignature like thing for a different presentation language, it would still be crazy)
  - amluto 2y ago
    Signatures in XML are nuts. So is all the mess built around RPC in XML, although IMO that’s not as bad as signatures. But the problem with signatures has nothing to do with XML per se in my opinion. I could just as easily come up with a similarly poor signature scheme in HTML (snicker), nasty C structs with endian issues, MIME, or even plain English. Hah, someone should make a signature scheme meant to be verified by an LLM that parses it and calls out to a helper to do the actual math :) Seriously, though, signing XML well is easy. Take some XML, serialize it to bytes, sign with libsodium, and transport the bytes of XML and the bytes of signature. But do not get cute and transport the signed XML as a subtree in another XML document: the bytes must bytes until the signature is verified. You could maybe get away with sticking it in another document as CDATA [0], but base64 would be better, since you basically can’t screw it up. And it’s entirely possible to screw even this up JOSE-style if you lose track of what a “key” is. DO NOT have the signed (document, signature) tuple specify the signature algorithm or parameters. All of that is part of the public key, which the verifier (obviously) needs to acquire out of band. [0] Someone may pwn, or at least massively confuse, you if you do this. Imagine what happens if the inner and outer documents have different character encodings.

bradly 2y ago

I was jamming this gem rails back in 2009-2010 and will tell you we had no idea what we were doing on our side either. We were a couple a Rails devs at a tiny start up implement Qualcomm's SSO and tbh I'm surprised it actually worked. 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.

runiq 2y ago
In case there are other people like me who don't know what 'two-legged authentication' is: https://stackoverflow.com/a/2880692 https://stackoverflow.com/a/2880692