XML Rewriting Attacks: Existing Solutions and their Limitations

Web Services are web-based applications made available for web users or remote Web-based programs. In order to promote interoperability, they publish their interfaces in the so-called WSDL file and allow remote call over the network. Although Web Services can be used in different ways, the industry standard is the Service Oriented Architecture Web Services that doesn’t rely on the implementation details. In this architecture, communication is performed through XML-based messages called SOAP messages. However, those messages are prone to attacks that can lead to code injection, unauthorized accesses, identity theft, etc. This type of attacks, called XML Rewriting Attacks, are all based on unauthorized, yet possible, modifications of SOAP messages. We present in this paper an explanation of this kind of attack, review the existing solutions, and show their limitations. We also propose some ideas to secure SOAP messages, as well as implementation ideas.

💡 Research Summary

The paper provides a comprehensive examination of XML rewriting attacks targeting SOAP‑based web services and evaluates the effectiveness of existing countermeasures. It begins by outlining the architecture of Service‑Oriented Architecture (SOA) web services, emphasizing the role of WSDL for interface description and SOAP for message exchange. The authors then describe how SOAP messages, despite being wrapped in WS‑Security signatures, remain vulnerable to structural manipulations that preserve the logical content while altering the XML tree. Three representative attack patterns—Element Wrapping, Signature Wrapping, and XPath Injection—are illustrated with concrete examples, showing how an attacker can relocate, duplicate, or encapsulate elements to bypass signature verification without breaking the service’s functional semantics.

The survey of existing defenses is organized into three categories. The first, whole‑message signing, attempts to protect the entire SOAP envelope with a single digital signature. While theoretically robust, this approach suffers from severe performance penalties for large payloads and is impractical when intermediaries need to modify routing headers or add security tokens. The second, schema‑based validation, relies on XML Schema or RelaxNG definitions to restrict permissible structures. This method works well in static environments but becomes cumbersome in dynamic service compositions where schemas evolve rapidly; moreover, the schema itself can become a target for manipulation, undermining its protective intent. The third, policy‑based access control, combines WS‑Policy statements with SAML or other token mechanisms to enforce security attributes. Because policy engines typically evaluate headers and bodies independently, they often fail to detect when an attacker has rearranged the body while preserving the signed header, allowing the attack to succeed unnoticed.

Across all surveyed solutions, the authors identify common shortcomings: a mismatch between the scope of the signature and the scope of verification, insufficient detection of structural changes, and the added complexity or latency introduced by the defenses. A particularly insightful observation concerns the reliance on XPath canonicalization during signature verification. Different implementations canonicalize XPath expressions in slightly different ways, leading to divergent hash values for semantically identical messages. Attackers can exploit this inconsistency to craft messages that appear valid under one implementation while being altered under another, effectively sidestepping the intended integrity check.

To address these gaps, the paper proposes a set of novel ideas. First, hierarchical signing would attach independent signatures to each critical SOAP element and embed explicit location metadata within the signature block. Any relocation of an element would cause a mismatch between the stored location and the actual position, causing immediate verification failure. Second, a dynamic policy engine would map the runtime structure of incoming messages to the expected signing scope, automatically tightening policies when anomalies are detected. Third, a multi‑level integrity check would combine a global envelope signature with a chain of per‑element hashes, creating a tamper‑evident structure similar to a Merkle tree. The authors suggest implementing these concepts as plug‑ins to existing WS‑Security stacks, leveraging open‑source XML security libraries to minimize performance overhead.

In conclusion, the paper argues that current defenses against XML rewriting attacks are fundamentally limited by their inability to robustly detect structural manipulation and by the operational costs they impose. The proposed hierarchical signing and dynamic policy mechanisms offer promising avenues for stronger protection, but they require standardization, extensive interoperability testing, and careful performance engineering before they can be adopted in production environments. The work thus serves both as a critical audit of the state‑of‑the‑art and as a roadmap for future research and practical deployment.