What is XML Signature wrapping?
XML Signature wrapping (XSW) is a class of cyberattacks that exploit the way XML signatures are validated in applications that use XML-based security protocols, particularly in Security Assertion Markup Language (SAML), Simple Object Access Protocol (SOAP) and Web Services Security (WS-Security or WSS).
Signature element wrapping attacks aim to bypass authentication and gain unauthorized access by manipulating the structure of an XML document without invalidating its digital signature.
An XML Signature wrapping attack exploits the gap between the signature validation process and data processing. The attacker injects a duplicate or manipulated element (like a forged SAML assertion or SOAP body) outside the signed portion, and the application ends up processing the malicious data.
Think Newsletter
Would your team catch the next zero-day in time?
Join security leaders who rely on the Think Newsletter for curated news on AI, cybersecurity, data and automation. Learn fast from expert tutorials and explainers—delivered directly to your inbox. See the IBM Privacy Statement.
Your subscription will be delivered in English. You will find an unsubscribe link in every newsletter. You can manage your subscriptions or unsubscribe here. Refer to our IBM Privacy Statement for more information.
Extensible Markup Language (XML) is a text-based data format used to structure and store data in a way that is both human-readable and machine-readable. It is used in web services, identity systems and data exchange between applications.
Like HTML, XML is structured with tags designed to represent data. It supports nested elements and attributes, allowing complex hierarchies.
XML is often used in SOAP, SAML and WS-Security protocols.
Example of XML
An XML Signature is a digital signature applied to XML data, defined by the W3C XML Signature specification. The XML Signature element helps ensure data integrity by asserting the data is trusted, verifiable and has not been tampered with.
- A part of the XML document is selected for signing by using a
<Reference> element with an ID (for example, #ID123).
A hash or digest is computed on that data.
The hash is encrypted with the sender’s private key to form the signature.
A
<Signature> block is added to the document with SignedInfo, which contains the reference URI, SignatureValue with the encrypted hash and KeyInfo such as public key or certificate.
Example of XML Signature syntax
<!-- Other details like DigestMethod, CanonicalizationMethod -->
XML Signature wrapping attacks exploit the structural flexibility of XML to trick applications into processing unauthenticated data while passing signature validation. Attackers create a mismatch between the element that is signed and the element actually processed (typically by duplicating or relocating elements). The result is that the application uses unsigned content, even though the signature appears valid.
Here’s how XML Signature Wrapping (XSW) attacks usually work:
Attackers start with a real, trusted XML message, such as a valid login response that is digitally signed (such as a legitimate SAML response).
They move the signed part (the one referenced in the
<ds:Reference URI=”#ID123”/> ) to a different place in the document where it is still technically present but not used.
They put forged data in the original location. This forged data isn’t signed but is crafted to look legitimate.
Most applications look for data by tag name or XPath expression, not by checking whether it is the signed version, so they end up using the forged data.
The digital signature still checks out because it’s verifying the original (now hidden) signed part, not the forged part the app uses.
So, the application thinks it is working with a secure signed document, but it’s really acting on unauthorized, manipulated data.
Walkthrough: An XSW attack in practice
This example demonstrates how an attacker can manipulate a signed SAML assertion to gain unauthorized admin access by exploiting weak XML parsing and validation logic.
SAML is an XML-based protocol used to safely exchange authentication information between two systems: the identity provider (IdP) and the service provider (SP). It enables single sign-on (SSO), allowing users to authenticate once and gain access to multiple services without repeated logins.
1. Original SAML request
This is a genuine SAML request captured by a tool such as SAML Raider in Burp Suite. It includes a digitally signed section, known as a SAML assertion, which contains the user’s identity details. Within this assertion is the
The request also contains a valid digital signature (
2. Observing the logged-in user
In the app’s response, it shows the user as logged in with the identity from the original
3. Modified SAML assertion (XSW attack performed)
The attacker secretly modifies the SAML request by moving the original, digitally signed assertion to another part of the XML document, allowing the signature to remain valid and pass verification.
A fake
This activity illustrates the core concept of an XSW attack: the digital signature appears valid, but the data processed by the application is fake and untrusted.
4. Successful admin access
As a result, the application grants admin access based on the fake assertion injected by the attacker. It fails to verify whether the assertion it processed was the one that was actually digitally signed. This failure allows the attacker to successfully impersonate an admin user. The system allowing the user to log in as admin@libcurl.so clearly demonstrates that the XML Signature wrapping attack succeeded.
This example shows how a weak XML signature check can be tricked into trusting fake data. The attacker doesn’t break the digital signature. Instead, the signed data is moved elsewhere, and fake information is placed where the app expects the real data. The application then mistakenly processes the fake data, believing it to be secure.
XSW attacks generally fall into a few main subsets or types, each exploiting the way XML Signature verification and parsing are implemented.
Here’s a breakdown of the most common ones:
1. Simple wrapping attack
Method: The attacker moves the signed element to a different part of the XML document and inserts a malicious element in its original place.
Goal: The signature still verifies (because the signed data is unchanged), but the application processes the attacker’s injected data instead.
Example: Signed
2. ID-based wrapping
Method: The attacker exploits the use of XML ID attributes to reference signed data.
Goal: Attacker creates a duplicate element with the same ID but places it in a location that the application processes first.
Example: The signature references #ID-1234, but the parser uses the attacker’s fake element with that ID instead of the signed one.
3. Namespace injection wrapping
Method: The attacker manipulates XML namespaces to confuse signature validation.
Goal: Change element interpretation or bypass strict schema checks while keeping the signature valid.
Example: Injecting a malicious <Assertion> element in a new namespace so that validation passes but processing logic accepts it.
4. XSW with enveloped signature abuse
Method: Modifies the placement of
Goal: Make the validator think everything is signed, but exclude attacker-controlled parts from the signature coverage.
Example: Move the original
5. XPath injection wrapping
Method: Manipulates XPath queries used during signature validation to point to attacker-controlled nodes instead of the signed node.
Goal: Trick the signature verifier into checking harmless data while the application processes malicious data.
Example: Tweak the XML so the verifier’s XPath (for example,
XSW attacks can lead to serious real-world consequences, particularly when sensitive data or critical operations are involved. These hypothetical scenarios highlight the potential impact of such attacks.
Scenario 1: Bypassing authentication in SAML SSO
Scenario: An enterprise application uses SAML-based single sign-on to authenticate users. Each login response includes a digitally signed SAML assertion identifying the user.
XSW attack: An attacker captures a legitimate SAML response, moves the signed assertion to a different part of the XML document and inserts a forged assertion claiming to be an admin in its place.
Impact: The system validates the signature on the original assertion but processes the unsigned, attacker-injected assertion, giving the threat actor access as a privileged user.
Scenario 2: Privilege escalation in web services
Scenario: A web service application programming interface (API) uses SOAP and WS-Security to process requests. The SOAP message body is digitally signed to help ensure that the command is trusted.
XSW attack: The attacker wraps the original, signed SOAP body in a harmless wrapper element and replaces it with a new unsigned body that contains elevated privileges or unauthorized actions.
Impact: If the service processes the unsigned body, the attacker can escalate privileges or perform restricted actions like viewing or modifying sensitive data.
Scenario 3: Unauthorized access to critical functionality
Scenario: An administrative interface allows users to submit XML-based commands, such as account deletion or password resets, protected by digital signatures.
XSW attack: The attacker moves the signed command to a secondary location and injects an unsigned command (such as deleting another user’s account or resetting an admin’s password) in its place.
Impact: If the application processes the unsigned command, it can carry out critical operations on behalf of an unauthorized user.
Scenario 4: Manipulating digitally signed payment requests
Scenario: A bank secures its fund transfer operations by using XML signatures. Each request contains transaction details such as the transfer amount and sender and receiver account numbers. Requests are digitally signed to help ensure authenticity.
XSW attack: An attacker captures a valid transfer request, relocates the signed data to a noncritical section of the document and inserts a forged transaction with a larger amount and a different recipient account.
Impact: If the application fails to strictly verify that the processed transaction is the one that was signed, it might execute the attacker’s forged transaction, resulting in unauthorized transfers and financial loss.
Scenario 5: Tampering with signed authentication tokens
Scenario: An online platform secures its authentication tokens by using XML digital signatures. Each token contains user identity information and access rights and is cryptographically signed to prevent tampering.
XSW attack: An attacker captures a valid authentication token, moves the signed portion to another location within the XML, and injects a new, unsigned segment that includes elevated or unauthorized privileges.
Impact: If the server processes the manipulated section instead of the signed one, the attacker can gain unauthorized access or perform privileged operations, compromising the security of the application.
To analyze whether an application is vulnerable to XML Signature wrapping attacks, it’s important to understand how it parses and processes XML data. It is especially important to understand XML parsing and processing in security-sensitive contexts such as SAML authentication or SOAP messaging.
Here are some techniques and testing strategies to identify such vulnerabilities in real environments:
1. Analyze how the application parses XML
Check whether the application extracts elements like
2. Use Burp Suite SAML Raider or custom proxies
Use Burp Suite with SAML Raider to inject a fake unsigned element and wrap the signed one. If the app processes the fake data while the signature still validates, it’s vulnerable to XSW.
3. Test for duplicate elements with same tag
Insert a signed assertion in a hidden section and a fake one in a visible spot. If the app processes the fake data, it’s vulnerable to XSW.
4. Check signature reference behavior
Relocate the signed element (the one referenced in
If the application processes the unsigned version instead of the one actually signed, then the application is vulnerable to an XSW attack. The app is validating the signature correctly but failing to ensure that it is using the signed content, allowing attackers to inject unauthorized data.
5. Review error handling and logging behavior
Send malformed assertions and observe verbose errors or inconsistent responses. These responses can expose weaknesses in the app’s XML security and validation logic.
6. Leverage known XSW exploitation techniques for testing
Use tools like SAML Raider, SoapUI or custom XML test harnesses to apply XSW attack patterns. If the application accepts and processes any of the payloads, it indicates an XSW vulnerability.
7. Inspect application code
If the app reads XML data by picking elements based on tag name without ensuring that it is using the signed, trusted element, it can be tricked into processing fake data.
To protect an application from XSW attacks, developers can implement strict XML processing, validate signatures correctly and ensure that only trusted, signed data is used.
Here are some specific countermeasures that can help to defend against XSW attacks:
Ensure that the exact XML element being used for authentication or authorization is the same one that was digitally signed. Doing so prevents attackers from injecting a second, unsigned assertion that the application might mistakenly process instead of the legitimate, signed one.
An enveloped signature is a signature placed inside the element that it signs. Enveloping makes it more difficult for attackers to insert malicious elements outside the signed content without breaking the structure, helping to prevent wrapping or substitution.
Use a secure XML parser configured to reject documents with duplicated IDs, external entity references or unexpected structure. XSW relies on manipulating the XML structure, such as by inserting duplicate tags or multiple assertions. Strict parsing reduces this attack surface by enforcing well-formed, schema-compliant input.
Tie the application’s processing logic directly to the XML element referenced in the signature (by using the ID attribute or signature
Reject SAML responses that contain more than one <Assertion> unless explicitly required. XSW attacks often inject a second assertion. Ensuring that only one is processed helps eliminate ambiguity and reduces risk.
Use well-maintained and security-conscious libraries for XML digital signature validation (such as Apache Santuario or OpenSAML) with secure default configurations. These libraries often include built-in protection against signature wrapping when properly configured.
Validate incoming SAML assertions against the official SAML XML Schema Definition (XSD). Validation prevents attackers from injecting unexpected elements or attributes that bypass business logic or confuse the XML parser.
Ensure that each ID attribute used in signed XML (such as assertions) is unique and that references match only one element. XSW exploits can succeed by referencing one element in the signature while injecting another with the same ID or tag name. Enforcing uniqueness helps avoid this confusion.
These practices can reduce the risk of attackers exploiting XML structures and signature processing logic, effectively closing the door on many XSW attacks.