SAML Security Vulnerabilities: How XML Signature Wrapping Attacks Work and How to Test Your Identity Provider Integration

A SAML 2.0 authentication flow works as follows:

1. User attempts to access the service provider (SP)
2. SP redirects user to the identity provider (IdP) with an AuthnRequest
3. User authenticates at the IdP
4. IdP issues a signed SAML Response containing an Assertion with the user's attributes (NameID, email, groups)
5. SP receives the response, validates the signature, extracts the NameID, and grants access

The signature in a SAML response signs a specific XML element (usually the Assertion). The signature includes a reference to the element ID being signed via the URI attribute. Validation confirms that the referenced element has not been tampered with.

The gap: the signature validates one element, but the application code may read authentication attributes from a different element. If an attacker can insert an additional element with the same tag name but different content, and if the application reads the first matching element rather than the specifically signed one, the attacker's element is processed as authoritative.

This is not a flaw in XML Signature itself. It is a flaw in the SP's assertion extraction logic failing to guarantee it reads from the signed element.

The 2012 Somorovsky research documented 8 XSW variants, each exploiting a slightly different parsing assumption:

XSW1 and XSW2: Insert a cloned Assertion with forged attributes before or after the signed Assertion. The signature references the signed Assertion by ID, but the SP's XPath query //saml:Assertion returns the first or last Assertion in document order, which is the attacker-controlled clone.

XSW3 and XSW4: Wrap the original signed Assertion inside the attacker-controlled Assertion. The signature still validates the inner element, but the SP reads attributes from the outer (unsigned) parent element.

XSW5: The signature is moved into the attacker's forged element. The SP validates the signature on the attacker element. The original signed element is attached but not the one the SP reads for attributes.

XSW6: Combines XSW5 with moving the original signed Assertion into the attacker's element's Extensions. The SP finds the signature and the claim elements in the expected relative positions but in an attacker-modified structure.

XSW7: Targets SPs that use the Assertion's ID attribute to locate the signed element. The attacker duplicates the ID on their forged element. Which element the SP finds depends on parser behavior.

XSW8: Uses the Extensions element as a wrapper to hide the original Assertion while presenting the forged one to the SP's XPath extraction.

In every variant, the goal is the same: make the signature validation pass while causing the SP to read attacker-controlled attribute values (NameID, email, role) for the session.

Beyond XSW, two additional SAML attack classes are found in assessments:

SAML Comment Injection: Some XML parsers handle comment nodes differently when evaluating XPath expressions. If the SP extracts the NameID using a string-based XPath rather than navigating the DOM, an attacker may insert an XML comment to manipulate which substring is returned:

Legitimate assertion:

<saml:NameID>user@legitimate.com</saml:NameID>

Manipulated assertion (if the signature covers a parent element and the NameID is not individually signed):

<saml:NameID>admin@legitimate.com<!---->.evil.com</saml:NameID>

In XML, <!----> is a valid empty comment. Some parsers return admin@legitimate.com as the text content before the comment; others return the full string including the comment content. If the SP's NameID extraction is affected by this differential, an attacker may manipulate the identity to a different user.

Parser Differential Attacks: Different XML parsers (Xerces, OpenSAML, Python's xml.etree) resolve namespace prefixes, entity references, and duplicate attributes differently. If the IdP's signing library and the SP's parsing library treat the same XML differently, the signed content is not the processed content.

The primary tool for SAML security testing is the SAML Raider extension for Burp Suite. Steps for a self-assessment:

Step 1: Capture a valid SAML Response Using Burp Suite as a proxy, complete a SAML login flow and intercept the POST request containing the SAMLResponse parameter (usually sent from the IdP to the SP's Assertion Consumer Service URL). The SAMLResponse is base64-encoded.

Step 2: Load into SAML Raider Send the intercepted request to Repeater. SAML Raider will detect and decode the SAML assertion, showing the XML structure.

Step 3: Apply XSW attacks In the SAML Raider tab, click the "XSW Attacks" button. The tool generates all 8 XSW variants and allows you to modify the NameID in the forged element (e.g., change it to another user's email address). Apply each variant and forward the modified request to the SP.

Step 4: Interpret the results

• If the SP returns HTTP 400 or 401: the XSW variant failed (signature validation rejected the manipulated assertion)
• If the SP grants access as the original authenticated user: XSW failed but the SP is still processing normally
• If the SP grants access with the identity from the forged element (the NameID you modified): the SP is vulnerable to that XSW variant

Manual test for comment injection: Modify the NameID value to include an XML comment character sequence and observe whether the SP processes the pre-comment substring or the full string as the identity.

Test without valid credentials: For a black-box test, obtain a valid assertion as any user (including a test account), then attempt to escalate to another user's identity via XSW. You do not need admin credentials to test; any valid assertion is sufficient.

The fix for XSW vulnerabilities is in how the SP extracts attributes from the assertion after signature validation:

Rule 1: Extract attributes only from the signed element After validating the signature, retain a reference to the specific signed element (by its ID). All subsequent attribute extraction must navigate from that specific element reference, not from a new XPath query against the full document.

# WRONG: Re-querying the document after validation
assert validate_signature(response_xml)
name_id = response_xml.find('.//saml:NameID', ns)  # may find forged element

# CORRECT: Extract from the validated element reference
signed_element = validate_signature_and_return_signed_element(response_xml)
name_id = signed_element.find('.//saml:NameID', ns)  # navigates from signed element only

Rule 2: Validate the assertion schema before processing Before signature validation, validate the assertion XML against the SAML 2.0 schema. A schema-valid assertion cannot contain duplicate IDs or unexpected wrapping elements. Schema validation catches many XSW structures before they reach the signature check.

Rule 3: Use a maintained SAML library Do not implement SAML parsing from scratch. Use actively maintained libraries that have had XSW patches applied:

• Python: python3-saml (OneLogin), pysaml2
• Java: OpenSAML 4.x, Spring Security SAML
• .NET: ComponentSpace SAML, Sustainsys.Saml2
• Node.js: samlify, node-saml

Verify the library version against its changelog and CVE history before deploying.

Rule 4: Enforce strict ID verification Ensure the signature's Reference URI attribute matches the ID of the element you intend to read. Do not process any assertion whose ID does not match the signed reference.