Sign in as anyone: Bypassing SAML SSO authentication with parser differentials

I recently had to implement SAML and this headline does not surprise me in the slightest.

The SAML spec itself is fairly reasonable, but is built upon XML signatures (and in turn, XML canonicalization) which are truly insane standards, if they can even be called such.

Only a committee could produce such a twisted and depraved specification, no single mind would be capable of holding and combining such contradictory ideas.

It would be so simple to just transmit signatures out-of-band and SAML would be a pleasure to implement.

It’s much worse than you’re making it sound: XML is literally an eXtensible Markup Language, so… of course the SAML standardisation committee invented their own extension mechanism language on top of it.

Coming up with your own protocol on top of a protocol for a tiny amount of data amounting to not much more than what’s in an authentication cookie is the special kind of stupid that only the largest and most bureaucratic committees can produce.

Is SSO salvageable at all? It seems like the idea of just logging into different accounts is fine.

Also just the idea of connecting your accounts together such that you can get megacompromised is foundationally riskier

One can use OIDC instead of SAML for SSO.

SAML is not the only standard for SSO. Before SAML we had Kerberos and nowadays you can use Open ID Connect. Other standards can have their own gotcha, but SAML is uniquely horrendous.

When we get vulnerabilities in the SSO protocol (SAML or otherwise) these vulnerabilities generally only affect some of the clients (identity consumers) who have implemented the protocol incorrectly or are using a feature that the provider has implemented incorrectly. Vulnerabilities that break the entire provider are less common.

When comparing this situation to having multiple different accounts, I can't see how SSO is less secure. Sure, when you have breach that affects the entire identity provider the damage is high, but the risk of having a breach (any breach!) is lower, since implementations are fewer, more consolidated and usually developed by people with better expertise.

OIDC is better than SAML, but that isn't a high bar. And OIDC has its own problems.

OIDC's problems are nothing like those of SAML.

The biggest problem with having separate accounts for everything is that a lot of the users will make their own "wish it were SSO" by setting their passwords in the systems to the same value. Then, when the weakest system is exploited, the attacker gets credentials that are valid across the organization. Yes, they should be using a password manager with unique, random passwords for each system, but realistically a good chunk of larger organizations' staff are not going to do that.

Some other headaches:

Having decentralised authentication means that onboarding and offboarding need to have a bunch of tedious manual steps, or custom automation.

Whoever does user support for the organization has to be trained to reset passwords/unlock accounts in a hodgepodge of systems.

Any security controls the organization wants to implement need to be reimplemented or approximated in a bunch of different systems. E.g. if there are regulatory requirements for account lockouts, time between explicit reauthentication, etc.

It becomes much more critical to collect the authentication logs/event data for all of those systems, and harmonize its formatting with everything else so that the security ops team isn't maintaining separate monitoring/alerting rules for every system.

For large-scale systems, there are also at least theoretically performance advantages to the kind of signed ticket approach that SSO mechanisms tend to use, versus having to do database lookups of session IDs or verify a password. It's possible to do that without SSO, but if you're going to the trouble of implementing that kind of mechanism, you're most of the way to having SSO anyway, and might as well just finish the job IMO.

Often password rules make slight variations of the passwords so that the damage is limited.

Furthermore, attackers don't try all accounts since they don't know which ones exist (unless they have email access).

"If there are regulatory requirements for account lockouts"

Then the vendor can impmenent those? The need for control might be a source for greater risk.

> Having decentralised authentication means that onboarding and offboarding need to have a bunch of tedious manual steps, or custom automation.

Furthermore, SAML SSO alone does not save you from worrying about this, ideally you'd also implement SCIM, to have actually automated + real-time identity updates, which is yet another protocol separate from SAML.

The SAML people aren't the most crazy ones though, the entire XML signature stuff is the insane part (You find it in other places such as xADES,SOAP,etc as well). In some misguided effort to avoid a inner-platform effect they made the decision to embed the signature in the structure itself being signed and thus enable these scenarios (needing canonical XML to verify things).

For any hate JWT gets, JSON-inside-JSON,etc, at least it architecturally avoids these kinds of security issues since you verify once and only read data from what has been verified and nothing else, instead of having to re-create data and hope that the loose structure doesn't mess things up.