OBSCURA OS
Settings

Read a SAML Response Without Handing Over the Login ASSERT

Paste a SAMLResponse, a SAMLRequest, the URL it came in or the XML, and see who it logs in, where, for how long, and what is wrong with it. It is decoded in this tab.

The message

Where to find one: the browser's developer tools, Network, tick "Preserve log", sign in, and find the POST to the service's sign-in address. SAMLResponse is in its form data. A SAMLRequest is usually in the address the service redirected you to.

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 [email protected]<!---->.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.

Questions people ask about ASSERT
Is it safe to paste a live SAML response here?

It is decoded and checked in this tab, and nothing is sent anywhere; the page works the same with the network off. A live response is still a working login until it expires, so treat the screen it is on the way you would treat a password.

What is XML signature wrapping?

An attack on the way SAML signatures point at what they sign. The attacker keeps the genuinely signed assertion in the message so the signature still checks, moves it somewhere the application does not read, and puts a forged assertion where it does. ASSERT reports the shapes that gives a message: a signature pointing at an element other than the one it sits in, a reference to an ID that is not there, duplicate IDs, and more than one assertion.

Does it verify the signature?

No, and on purpose. Doing it correctly needs exclusive XML canonicalisation reproduced exactly and the identity provider's certificate from configuration, not from the message. A verifier that is nearly right is worse than none. ASSERT shows the shape of every signature and the fingerprint of the certificate that came with it, for comparison with the one the service provider trusts.

Why does a SAMLRequest in a URL look like random letters?

The redirect binding compresses the XML with deflate, then base64-encodes it, then URL-encodes that. ASSERT undoes all three. A SAMLResponse posted in a form is base64 without the compression.

Why is a comment in the NameID serious?

Because several SAML libraries read an element's text only up to the first comment. An attacker registers [email protected]<!---->.attacker.test, gets it signed by the identity provider, and the application reads it as [email protected]. No legitimate identity provider has a reason to put a comment there.

Can it read an encrypted assertion?

No. An EncryptedAssertion opens only with the service provider's private key, which should never leave its server. ASSERT says the assertion is encrypted, which is good, and reads everything around it.

Related tools