3 ms·

I feel most responses to vulnerabilities are so lenient, you have to throw out some baby with the bathwater, you can't surgically remove the dangerous component

I feel most responses to vulnerabilities are so lenient, you have to throw out some baby with the bathwater, you can't surgically remove the dangerous component, you gotta chop and throw chemotherapy en masse. If you are an IT admin with any pride, SAML is out of any future plans. The idea of SSO is suspect as a whole. Xml parsing has been hit twice in a week, avoid it in the future, anything wrong with a policy that replaces xml with json?

tptacek 2y ago
For an organization of any significant size (say, anything over 10 people), not deploying SSO would be malpractice. The point of SSO is to have a single point of control and a single, mandatory 2FA stack. Obviously, if you can avoid doing SSO with SAML, you should.
unscaled 2y ago
> Xml parsing has been hit twice in a week, avoid it in the future, anything wrong with a policy that replaces xml with json? OAuth 2.0 and its extension Open ID Connect have been around for over a decade. They have their own gotchas (like in badly defined ID token in OIDC and the ill-thought implicit and hybrid flows), but nothing there is nearly as dangerous as SAML. Most applications support Open ID Connect now, but I'm still seeing organization choosing to use SAML out of inertia even when they are fully capable of using Open ID Connect.
L-four 2y ago
Parse this JSON correctly ```json { "data": "XXX", "sig": "BAD", "sig": "GOOD" } ```
- TheDong 2y ago
  In a security sensitive context, a parser should return an error on a duplicate key regardless what common parsers do and what the RFC fails to specify. Implicitly, that means no security software dealing with json should be written in Go, Javascript, ruby, python, etc (where practically everyone uses json parsers that silently ignore duplicate keys) Plenty of languages do have common json libraries w/ duplicate key errors, like haskell (aeson), rust (serde_json), java (gson, org.json, probably others), so there's plenty of good choices. So yeah, correct parse result is '400 bad request'
  - chrome111 2y ago
    For Java, I think you mean Jackson, not gson, unless something has changed recently. Goes to show that even the behemoths can get this wrong. https://github.com/protocolbuffers/protobuf/blob/6aefdde97363556ccbbc2dcb946366e54025c5b8/java/util/src/test/java/com/google/protobuf/util/JsonFormatTest.java#L566 https://github.com/protocolbuffers/protobuf/blob/6aefdde9736...
- TZubiri 2y ago
  I overwrite with the last one. Strictly not a parser problem. Csv is also available. And binary protocols, with index based implicit keys are and byte length prepended to variable length fields. Those are the gold standard (see ip and tcp headers.)

tptacek 2y ago

For an organization of any significant size (say, anything over 10 people), not deploying SSO would be malpractice. The point of SSO is to have a single point of control and a single, mandatory 2FA stack. Obviously, if you can avoid doing SSO with SAML, you should.

unscaled 2y ago

> Xml parsing has been hit twice in a week, avoid it in the future, anything wrong with a policy that replaces xml with json? OAuth 2.0 and its extension Open ID Connect have been around for over a decade. They have their own gotchas (like in badly defined ID token in OIDC and the ill-thought implicit and hybrid flows), but nothing there is nearly as dangerous as SAML. Most applications support Open ID Connect now, but I'm still seeing organization choosing to use SAML out of inertia even when they are fully capable of using Open ID Connect.

L-four 2y ago

Parse this JSON correctly ```json { "data": "XXX", "sig": "BAD", "sig": "GOOD" } ```

TheDong 2y ago
In a security sensitive context, a parser should return an error on a duplicate key regardless what common parsers do and what the RFC fails to specify. Implicitly, that means no security software dealing with json should be written in Go, Javascript, ruby, python, etc (where practically everyone uses json parsers that silently ignore duplicate keys) Plenty of languages do have common json libraries w/ duplicate key errors, like haskell (aeson), rust (serde_json), java (gson, org.json, probably others), so there's plenty of good choices. So yeah, correct parse result is '400 bad request'
- chrome111 2y ago
  For Java, I think you mean Jackson, not gson, unless something has changed recently. Goes to show that even the behemoths can get this wrong. https://github.com/protocolbuffers/protobuf/blob/6aefdde97363556ccbbc2dcb946366e54025c5b8/java/util/src/test/java/com/google/protobuf/util/JsonFormatTest.java#L566 https://github.com/protocolbuffers/protobuf/blob/6aefdde9736...
TZubiri 2y ago
I overwrite with the last one. Strictly not a parser problem. Csv is also available. And binary protocols, with index based implicit keys are and byte length prepended to variable length fields. Those are the gold standard (see ip and tcp headers.)