SAML Signature Wrapping (XSW)

SAML assertions are XML documents protected by XML Digital Signatures. Signature Wrapping (XSW) exploits a subtle gap: the signature validates one element, but the application logic reads a different one.

How it works

A SAML response contains a signed <Assertion>. The attacker keeps the original signed assertion intact (so signature validation passes) but injects a second, unsigned assertion containing role=admin. Depending on how the parser resolves elements:

• The signature library checks the signed assertion and reports "valid".
• The application then reads attributes from the first/wrapped/unsigned assertion the attacker injected.

The mismatch — validate-here, read-there — is the whole bug. Variants move the signature into a wrapper element, duplicate IDs, or exploit Reference URI resolution.

How to test

Capture a valid SAMLResponse, then construct XSW variants: inject an assertion as a sibling/child, duplicate the Assertion with a forged role, and shuffle which element carries the Signature. If the SP accepts elevated attributes, it's vulnerable. Tools like SAML Raider automate the permutations.

Impact

Authentication bypass and privilege escalation across the entire SSO trust — log in as any user or as an administrator.

Defenses

• Validate that the signature covers exactly the assertion the application consumes (same element, by reference).
• Use a hardened, schema-validating SAML library; reject multiple assertions and duplicate IDs.
• Process only the signed element; discard anything outside it.