Thread

1. bawolff · 1790112822 · focus · HN ↗

   My favourite SAML horror story, is that it used to be, that by default the main c implementation of xmlsig would not just check the sig with the public key specified but would also:

   - check it against an hmac using a password specified in the attacker controlled document.

   - check the signature using web pki (so the attacker could sign the saml document with their TLS key for their own personal domain and it would always be considered valid)

   I honestly dont know how sites with saml arent getting hacked all the time. The only thing worse than the absolute terrible standards are the absolute terrible implementations.

   1. stouset · 1790113441 · focus · HN ↗

      I saw multiple implementations that looked for a signature, verified it, then just trusted the document as a whole rather than only the part that was signed. So as long as you had any signed SAML doc, you could provide an attention of your choosing and just bundle the signed one somewhere arbitrary inside of it.

      1. tptacek · 1790113661 · focus · HN ↗

         It really probably is the worst security specification ever written.

         1. koolba · 1790116361 · focus · HN ↗

            The root problem with SAML is there’s a million and one permutations to do the same thing.

            Signed assertions. Signed messages. Encrypted messages. Encrypted assertions. Sign after normalization. Sign before normalization. Encrypt then sign. Sign then encrypt.

            There’s too many ways to do too many things.

            1. pseudohadamard · 1790151629 · focus · HN ↗

               That's because its built in part on XMLDSig, a genius idea to sign active content that can redefine its own semantics as it's being signed/verified. It's a triumph of ideology over common sense.

               1. [deleted] · 1790153759 · focus · HN ↗

                  [deleted]

Unofficial Hacker News client; not affiliated with Y Combinator.