Disable DTD and external entity parsing to prevent XXE attacks; 2. Verify and clean input data using strict XSD mode; 3. Limit the number of entity extensions, document size and nesting depth to resist XML bombs; 4. Enable WS-Security for SOAP services, verify envelopes, and limit WSDL exposure; 5. Prioritize safer data formats such as JSON and continuously update XML processing libraries. Through multi-layer defense policies, all XML input can be strictly processed, which can effectively prevent data breaches, denial of service, and remote code execution risks.

Web services often rely on XML for data exchange, especially in legacy systems using SOAP or other XML-based protocols. While XML is powerful and structured, it introduces security risks—particularly XML-based injection attacks , which can lead to data theft, denial of service, or remote code execution. Securing web services against these threats require a layered defense strategy.

Here's how to effectively protect your systems:

1. Validate and Sanitize All XML Input

Never trust incoming XML data. Attackers can embed malicious payloads in seemingly valid XML structures.

• Use strict schema validation (XSD) : Define and enforce a tight schema for accepted XML. Reject any document that doesn't conform.
• Implement input sanitization : Strip or escape dangerous constructs like external entities, processing instructions, or CDATA sections if not required.
• Reject XML with DTDs (Document Type Definitions) : Unless absolutely necessary, disable DTD processing entirely. Many XML injection attacks (like XXE) rely on DTDs.

Example: An XXE attack might look like:

 <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<data>&xxe;</data>

If DTD parsing is enabled, this could expose sensitive server files.

2. Prevent XXE (XML External Entity) Attacks

XXE is one of the most common and dangerous XML injection flaws. It exploits the parser's ability to resolve external entities.

Mitigation steps:

• Disable external entity resolution in your XML parser:
  • In Java (eg, using DocumentBuilder ):

     DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
    factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
    factory.setFeature("http://xml.org/sax/features/external-general-entities", false);

  • In .NET, avoid XmlDocument with DTDs enabled; use XmlReader with secure settings.
• Use safer data formats when possible : Consider switching to JSON over XML for new services, especially if SOAP isn't required.
• Patch and update XML processors : Old libraries (like certain versions of Xerces or libxml2) have known XXE vulnerabilities.

3. Guard Against XML Bomb (Billion Laughs Attack)

This denial-of-service attack uses entity expansion to consume massive memory.

Example:

 <!DOCTYPE bomb [ 
  <!ENTITY a "1234567890">
  <!ENTITY b "&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;&a;">
  <!ENTITY c "&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;&b;">
  ...
]>
<data>&c;</data>

Even small payloads can expand into gigabytes of data.

Defenses:

• Set limits on:
  • Entity expansion count
  • Document size
  • Nesting depth
• Use parsers that support these limits natively (eg, Java's XMLConstants.FEATURE_SECURE_PROCESSING )
• Consider using streaming parsers (like SAX or StAX) that don't load the entire document into memory

4. Secure SOAP and WSDL Interfaces

SOAP-based services are particularly vulnerable if not hardened.

• Use WS-Security for message-level encryption and signing.
• Validate SOAP envelopes against schema.
• Disable WSDL exposure in production if not needed, or restrict access.
• Watch for SOAPAction spoofing or parameter tampering.

Tip: Use tools like SOAP UI carefully in testing environments, but ensure endpoints aren't exposed to unauthorized users.

Final Notes

XML injection attacks are often overlooked in modern apps shifting to JSON, but many enterprise systems still rely on XML. The key is never to parse untrusted XML with default, permitive settings .

Best practices summary:

• Disable DTDs and external entities
• Validate input with schema
• Limit parsing resources
• Keep XML libraries updated
• Prefer simpler, safe formats when feasible

Basically, treat XML like any untrusted input—validate, restrict, and verify. Most attacks succeed not because XML is inherently bad, but because parsers are left too open. Lock them down, and you eliminate most risks.

The above is the detailed content of Securing Web Services Against XML-Based Injection Attacks. For more information, please follow other related articles on the PHP Chinese website!