Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

mattermost.com

Post reply on HN
Print view View original

111–115 of 115 posts

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#111

Post by KajMagnus »

ucarion wrote: post #107
KajMagnus wrote: post #82

Earlier quoted context omitted.

What about SCIM, "System for Cross-domain Identity Management", instead of SAML, if creating software for enterprises? SCIM: https://docs.microsoft.com/en-us/azure/active-directory/app-...

SCIM is a pleasure to implement compared to SAML, no doubt. You might be able to get away with only supporting SCIM, the main thing you'd be missing is "just-in-time" user provisioning. But given that you'll probably need SCIM at some point anyway, probably a good idea to start with SCIM, and then add SAML only when you need to! It'll also inform what subset of SAML you actually need to implement.

> good idea to start with SCIM, and then add SAML only when you need to

Sounds like a good approach yes. (It seems you've added SCIM to some software? About how long did it take? Was there any "gotchas")

> the main thing you'd be missing is "just-in-time" user provisioning

Hmm could that depend on the organization using the software I'm developing? — Possibly they'll synchronize user accounts and groups, upon installation of the software, and whenever anything changes — and then all user accounts will be ready already, when someone wants to log in.

But if they syncronize only, say, once a day, then, with SAML, one could still log in, and the account would get created and added to the correct groups, also if the sync that would create one's account, hadn't happened yet? (OIDC could help a bit, but it doesn't understand user groups and permissions, only SAML and SCIM does, right.)

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#112

Post by masklinn »

hakre wrote: post #96
ptman wrote: post #95

Earlier quoted context omitted.

Pardon my ignorance, but what should be used instead of encoding/xml?

I think libxml does not have that problem, IIRC golang supports c-bindings.

> I think libxml does not have that problem

I don't know about that. libxml certainly doesn't round-trip XML documents in general (though I don't think it breaks namespaces at least), whether that breaks SAML or not I have no idea.

Anyway from tptacek's other comments it looks like general-purpose XML libraries should not be assumed suitable for SAML, instead they should have purpose-built implementation for the SAML bit, then once the document has been properly validated and the SAML bits stripped off I guess that can be passed onto a general-purpose library:

> SAML libraries should include purpose-built, locked-down, SAML-only XMLDSIGs, and those XMLDSIGs should include purpose-built, stripped-down XMLs.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#113

Post by tptacek »

masklinn wrote: post #112
hakre wrote: post #96

Earlier quoted context omitted.

I think libxml does not have that problem, IIRC golang supports c-bindings.

> I think libxml does not have that problem I don't know about that. libxml certainly doesn't round-trip XML documents in general (though I don't think it breaks namespaces at least), whether that breaks SAML or not I have no idea. Anyway from tptacek's other comments it looks like general-purpose XML libraries should not be assumed suitable for SAML, instead they should have purpose-built implementation for the SAML…

I would go out of my way to avoid libxmlsec1 and libxml. I honestly don't understand why it's so hard for a SAML implementation to just bring its own hardened stripped-down XML.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#114

Post by masklinn »

tptacek wrote: post #113
masklinn wrote: post #112

Earlier quoted context omitted.

> I think libxml does not have that problem I don't know about that. libxml certainly doesn't round-trip XML documents in general (though I don't think it breaks namespaces at least), whether that breaks SAML or not I have no idea. Anyway from tptacek's other comments it looks like general-purpose XML libraries should not be assumed suitable for SAML, instead they should have purpose-built implementation for the SAML…

I would go out of my way to avoid libxmlsec1 and libxml. I honestly don't understand why it's so hard for a SAML implementation to just bring its own hardened stripped-down XML.

If I had to hazard a guess, bespoke implementation is usually recommended against, especially for complex formats. That it would be the best practice for saml does sound counter-intuitive.

Re: Coordinated disclosure of XML roundtrip vulnerabilities in Go’s standard library

#115

Post by tatersolid »

KajMagnus wrote: post #85
xyzzy_plugh wrote: post #38

Earlier quoted context omitted.

I don't doubt it was a mistake, but I'm curious what the alternative is here? I'm looking to add SAML to my to project in the medium-term.

> I'm looking to add SAML to my to project in the medium-term Did you hear about SCIM, "System for Cross-domain Identity Management"? If combining with OIDC, then, seems to me one gets a more modern alternative to SAML. I've read just a bit about SCIM though. SCIM: https://docs.microsoft.com/en-us/azure/active-directory/app-... I wrote more in this comment: https://news.ycombinator.com/item?id=25425665 (What's your p…

If you want enterprise customers, you still need to support SAML in 2020.
Post reply on HN