SAML XML Signature Wrapping (XSW): Break SSO Assertions

SAML XML Signature Wrapping (XSW): Break SSO Assertions

SAML SSO fails open in a very specific way: the service provider verifies that some XML was signed by the IdP, then reads identity from a different part of the document. Signature wrapping (XSW) exploits that mismatch. You keep the valid signature over the original assertion and smuggle a second, unsigned (or differently placed) assertion that the app actually consumes.

Mental model

A Response arrives with an Assertion stating NameID=victim@corp. The signature covers that assertion. You wrap or duplicate nodes so:

• The cryptographic verify still walks the original signed subtree
• The application’s business logic reads NameID=attacker@corp (or an admin user) from another subtree

Same bytes can satisfy a naive “signature valid?” check and a gullible XML parser path.

Where hunters look

Enterprise apps with “Login with SAML,” older Java SAML stacks, custom PHP parsers, and anything that logs “signature verified” while dumping a different Subject. Capture a full AuthnResponse from a test IdP you control or from a lab. Never poke a production IdP with malformed XML unless the program explicitly allows it.

Variants you will hear numbered

Researchers catalog XSW1–XSW8 style mutations: move the signed assertion under a sibling extension element, duplicate Assertion IDs, nest a fake assertion where some libraries call getElementsByTagName("Assertion")[0]. Exact XML differs by library. The invariant is verify-one-node / trust-another-node.

If the SP canonicalizes and verifies the exact element it later parses, wrapping dies. Most successes I have seen were “verify Response signature loosely, then take the first Assertion child that looks right.”

Practical lab workflow

Use a SAML test IdP and a vulnerable SP image, or PortSwigger / OWASP-aligned labs that still teach assertion tampering. Burp extensions that decode SAML help you edit Base64 SAMLResponse values. After each mutation:

1. Confirm the SP still accepts the response (no immediate signature error)
2. Land in a session whose identity matches your injected NameID / AttributeStatement
3. Show privileged data access

That trio is the report. XML diffs alone do not sell severity.

Related SAML bugs (do not conflate)

Comment injection in XML, XXE in SAML parsers, expired assertion acceptance, and Audience / Recipient mismatches are sibling issues. Mention them only if you tested them. XSW is specifically about signature subtree confusion.

Fix guidance worth pasting

Verify signatures against the exact elements used for authorization decisions. Prefer hardened libraries with wrapping protections. Schema-validate tightly. Reject documents with duplicate IDs or multiple Assertions when only one is expected. Align with CWE-347 and SSO hardening guides from your IdP vendor.

Reporting tone

Assume the triage engineer has seen “SAML is broken” noise. Lead with: which node was signed, which node was trusted, and which account you obtained. Attach redacted XML before/after. If you only changed attributes inside a correctly signed assertion without a crypto bypass, that is a different bug class — do not label it XSW.

Wrapping still shows up on mature targets because XML and crypto code rarely share one owner. When they disagree, SSO becomes a confused deputy.