Read a SAML response without handing over the login ASSERT

A SAML response is a login, not a log line

When single sign-on works, the identity provider hands your browser a signed statement saying who you are, and your browser posts it to the service. Whoever holds that statement, inside its validity window, can usually post it to the same service and be you. It also carries your name, your email address, your groups and whatever else your organisation's identity provider was set up to send.

When single sign-on breaks, the standard advice is to paste that statement into a SAML decoding website. Most of those sites are run by decent people, and each of them is a single breach away from holding a pile of other people's live logins and personal details. Decoding it is base64 and sometimes a decompression: there is no reason for it to leave the browser.

What it checks

• Signature wrapping. An XML signature points at what it signs by ID. The classic attack moves the signed assertion somewhere the application does not look and puts a forged one where it does. Its fingerprints are a signature whose Reference points at something other than the element it sits in, a Reference that points at nothing, two elements with the same ID, and more than one assertion. Each is reported.
• Nothing signed at all. Neither the response nor the assertion carrying a signature over itself.
• The comment trick. Several SAML libraries read an element's text only up to a comment, so user@example.com<!---->.attacker.test is signed as one address and read as another. A comment inside a NameID or an attribute value is reported.
• A DOCTYPE. A SAML message never needs one, and XML entity attacks always do. A message carrying one is not parsed here at all.
• The conditions. No audience restriction, no time limit on a bearer confirmation, a validity window measured in hours or days, Destination and Recipient disagreeing, and an unsolicited response with no InResponseTo.
• Algorithms. SHA-1 in the signature or the digest, and transforms other than the canonicalisation SAML uses.

Why it does not say "signature valid"

Checking an XML signature means reproducing exclusive canonicalisation of the signed element exactly, then checking the digest and the signature against the identity provider's certificate. A verifier that is nearly right is the dangerous kind: wrapping attacks exist precisely because verifiers that looked right said "valid" about documents built to fool them. So ASSERT reports the shape of each signature, which is where the attacks show, and the SHA-256 fingerprint of the certificate that came with it. The certificate in the message proves nothing by itself, because anybody can put one there; compare the fingerprint with the one the service provider trusts, and open it in CERTLENS to see who it names and when it expires.

For an OpenID Connect or OAuth token instead, JOT reads it. For a SAML message that turns up inside a capture, WIRE reads the capture and INTERCEPT cleans it before it is shared.