←back to thread

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

(github.blog)
312 points campuscodi | 4 comments | 15 Mar 25 19:06 UTC | HN request time: 0.656s | source
Show context
wcoenen ◴[15 Mar 25 20:46 UTC] No.43375039[source]▶
Isn't the simpler conclusion here that one should look for the signature where it is supposed to be? Instead of using an excessively general XPath like "//ds:Signature" that might find any signature in any unexpected location...
replies(2): >>43375138 #>>43375746 #
TZubiri ◴[15 Mar 25 23:06 UTC] No.43375746[source]▶
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?

replies(3): >>43375854 #>>43376192 #>>43376361 #
1. L-four ◴[16 Mar 25 01:34 UTC] No.43376361[source]▶
Parse this JSON correctly ```json { "data": "XXX", "sig": "BAD", "sig": "GOOD" } ```
replies(2): >>43377624 #>>43378728 #
2. TheDong ◴[16 Mar 25 08:31 UTC] No.43377624[source]▶
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'

replies(1): >>43378137 #
3. chrome111 ◴[16 Mar 25 11:13 UTC] No.43378137[source]▶
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/6aefdde9736...

4. TZubiri ◴[16 Mar 25 13:04 UTC] No.43378728[source]▶
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.)