SAML Decoder

What is SAML?

SAML, or Security Assertion Markup Language, is a standard for exchanging XML assertions about authentication, attributes and authorisation. It is commonly used for SSO: an identity provider sends an application an assertion about a user, which the application must validate before granting access.

Flows and the two bindings

SAML 2.0, an OASIS standard published in March 2005, carries an identity from an identity provider (IdP) to a service provider (SP) through the user’s browser. In the SP-initiated flow, the user lands on the application, the SP builds an AuthnRequest and sends the browser to the IdP. After authentication, the IdP returns a Response holding an assertion, with InResponseTo set to the request ID, to the SP’s Assertion Consumer Service (ACS). In the IdP-initiated flow, the user starts from an IdP portal and the response arrives with no prior request: nothing ties it to an SP session, which makes it easier to replay or to inject into a victim’s browser.

The HTTP-Redirect binding carries the message in the URL: it is compressed with raw DEFLATE (RFC 1951), base64-encoded, then URL-encoded (SAML Bindings, §3.4.4.1). Compression is there because browsers and servers limit URL length. The signature is detached: the SigAlg and Signature parameters are computed over the query string. This binding is mostly used for requests, which are shorter than responses. The HTTP-POST binding puts the message, base64-encoded and uncompressed, in an HTML form that submits itself: almost every response travels this way, with its signature inside the XML. The tool infers the binding from the encoding it meets and lists every decoding step.

What the signature covers

An enveloped XML signature (ds:Signature) sits inside the element it protects and points to it with a Reference whose URI is # followed by its ID. SAML Core (§5.4.2) requires a single reference, to the signature’s parent element. Signing the Response protects all of its content, assertion included. Signing only the assertion protects the identity, dates and audience; the status and the attributes of the Response itself remain open to change. Both setups are valid; the danger comes from an SP that verifies one element and then reads another.

Exclusive canonicalisation removes comments and normalises the markup before the digest is computed. A message can therefore change its appearance without breaking the signature, and any difference between what the verifier reads and what the application reads becomes a flaw. The tool shows the target of each reference, the algorithms and the transforms; it does not verify the signature itself.

Classic attacks

XML Signature Wrapping

The attacker keeps the signed assertion, so that verification succeeds, and adds an assertion of their own that the application reads instead: as the first child of the Response, with the same ID, or by moving the original into Extensions. Somorovsky et al. found the flaw in 11 of the 14 implementations they studied (On Breaking SAML, USENIX Security 2012). It keeps coming back: in 2024, CVE-2024-45409 in ruby-saml, then in March 2025 CVE-2025-25291 and CVE-2025-25292, two differences between the REXML and Nokogiri parsers described by GitHub Security Lab.

Comment truncation

Published by Duo Labs on 27 February 2018 (VU#475445): the attacker obtains a signed assertion for admin@sp.example.attacker.example, then inserts a comment into the NameID, admin@sp.example<!---->.attacker.example. The signature still verifies because canonicalisation ignores comments, but a library that reads only the first text node gets admin@sp.example. Several libraries were affected, including python-saml (CVE-2017-11427), ruby-saml (CVE-2017-11428) and OmniAuth-SAML (CVE-2017-11430).

XXE and unvalidated certificates

The SP parses the XML before it checks anything, so a DTD with external entities reaches the parser without authentication. Another frequent mistake is verifying the signature with the certificate found in KeyInfo: the attacker then signs with their own key and the message is accepted.

Replay and Golden SAML

Without checks on NotOnOrAfter, the audience and already consumed IDs, an intercepted assertion can be replayed. Golden SAML, described by CyberArk in November 2017, goes further: with the IdP signing key (for instance taken from an AD FS server), the attacker forges valid assertions for any user. The technique was used in the SolarWinds campaign, as described in CISA alert AA20-352A of 17 December 2020, which lists tokens with an unusual validity period among the signs to look for.

Testing an SP with Burp and SAML Raider

SAML Raider, a Burp extension maintained by Compass Security, intercepts SAML messages, decodes them and offers the eight XSW variants, signature removal, XXE payloads and re-signing with a test certificate. This tool is for reading a message outside Burp, spotting what to test and preparing a modified value.

• Log in with a test account, capture the SAMLResponse posted to the ACS and paste it here to read signatures, dates, audience and attributes.
• Replay it unchanged after expiry, then a second time before expiry: both must be rejected if the SP remembers IDs.
• Remove the signatures in the workshop, re-encode for POST and replace the value: the SP must reject it.
• Change the NameID or a role attribute without removing the signature, then try comment truncation and the XSW variants with SAML Raider.
• Re-sign with your own certificate (SAML Raider) to check that the SP does not use the key from the message.
• On the IdP side, change the AssertionConsumerServiceURL of an AuthnRequest to check that an unregistered ACS is refused.

Defence

• Use a maintained, up-to-date SAML library; do not reimplement verification or assertion extraction.
• Verify the signature with the IdP metadata certificate only, require rsa-sha256 and a sha256 digest, and reject any unsigned message.
• Process exactly the element the signature covers, and reject duplicate IDs and responses with several assertions.
• Configure the XML parser to refuse any DTD, and do not read an element’s text node by node.
• Check Destination, Recipient, Audience, NotBefore, NotOnOrAfter and InResponseTo, and remember consumed IDs until they expire.
• Protect the IdP signing key like a domain secret and watch for federated logins with no matching authentication on the IdP side, a sign of Golden SAML.