DTD - DTD Security Considerations and Entity Expansion Risks

 

DTD security is an important topic when XML documents are processed by applications, because DTDs can define entities that cause an XML parser to perform additional processing. If external entities or large numbers of entity references are accepted without proper restrictions, attackers may exploit these features to access sensitive resources, consume excessive system resources, or disrupt an application.

1. What Are Entity Expansion Risks?

An entity is a named piece of data that can be referenced within an XML document. For example:

<!DOCTYPE message [
  <!ENTITY greeting "Hello World">
]>
<message>&greeting;</message>

When the XML parser processes the document, &greeting; is replaced with Hello World. This process is called entity expansion.

Entity expansion is normally useful, but problems can occur when an application processes a very large number of entities or entities that recursively reference one another. The parser may have to perform a huge amount of work while processing a relatively small XML document.

2. Billion Laughs Attack

One well-known XML security problem is the Billion Laughs attack, also called an XML entity expansion attack.

A malicious DTD can define entities that expand into increasingly larger strings:

<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
]>

Each entity refers to the previous entity multiple times. As the parser expands them, the amount of generated data can grow dramatically.

The original XML document may therefore be very small, while the amount of data created during parsing becomes extremely large. This can consume significant amounts of memory and CPU and may cause the application to slow down or stop responding.

3. External Entity Risks

DTD security concerns are not limited to excessive entity expansion. XML also supports external entities, which can refer to resources outside the XML document.

For example:

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

If an XML parser permits external entity processing, it may attempt to read the referenced file. Depending on the application's privileges and parser configuration, sensitive information could potentially be exposed.

This type of vulnerability is commonly associated with XML External Entity (XXE) attacks.

External entities can also refer to network resources. A malicious XML document could potentially cause a server to make requests to locations that the attacker chooses. This creates additional security risks, particularly for applications that process XML received from untrusted users or external systems.

4. Denial-of-Service Risk

Entity expansion can also create a denial-of-service (DoS) condition.

Suppose an application accepts XML uploaded by users. An attacker could submit an XML document specifically designed to make the parser consume excessive CPU or memory.

The application's normal workflow might be:

User submits XML
        |
        v
XML parser processes DTD
        |
        v
Entities are expanded
        |
        v
CPU/memory usage increases
        |
        v
Application becomes slow or unavailable

The attacker does not necessarily need to compromise the server directly. Causing the XML parser to consume excessive resources may be enough to disrupt the service.

5. Why External DTDs Can Be Dangerous

An XML document can reference a DTD stored somewhere else:

<!DOCTYPE document SYSTEM "external.dtd">

This creates another security consideration. If the parser automatically retrieves external DTDs, processing the XML document may involve reading local files or communicating with external systems.

For applications processing untrusted XML, automatically loading external DTDs can therefore increase the attack surface.

Developers should carefully consider whether external DTD loading is actually required. If it is unnecessary, disabling it can significantly reduce the associated risks.

6. Safe XML Parser Configuration

One of the most effective ways to reduce DTD-related security risks is to configure the XML parser securely.

Depending on the programming language and XML parser, security controls may include:

  • Disabling external entity processing.

  • Disabling external DTD loading.

  • Preventing access to local files through external entities.

  • Preventing network access during XML parsing.

  • Limiting entity expansion.

  • Limiting the size and depth of XML documents.

  • Using secure parser configurations provided by the platform.

  • Rejecting XML documents containing unnecessary DTD declarations.

The exact configuration depends on the XML library being used, so developers should consult the security documentation for their specific parser.

7. Entity Expansion Limits

Modern XML parsers may provide limits that restrict how much work can be performed during entity expansion.

For example, a parser may limit:

Maximum entity size
Maximum number of entity references
Maximum XML document size
Maximum nesting depth
Maximum expansion size

These restrictions help prevent a small malicious XML document from causing disproportionately large processing requirements.

However, simply relying on size limits is not always sufficient. External entity access should also be restricted when processing untrusted XML.

8. DTDs and Untrusted XML

The greatest security concern arises when an application processes XML supplied by an untrusted source.

Examples include:

  • XML uploaded through a website.

  • XML received through an API.

  • XML submitted through a form.

  • XML received from third-party systems.

  • XML files provided by unknown users.

  • XML messages received through integration services.

If the source is trusted and controlled, the risks may be easier to manage. If the source is untrusted, the application should assume that the XML document may contain intentionally malicious DTD declarations or entity definitions.

9. DTD Security in Application Development

Consider an application that accepts an XML configuration file:

<configuration>
    <username>admin</username>
    <database>production</database>
</configuration>

If the application simply parses this XML using a secure parser configuration, processing is relatively straightforward.

However, an attacker could attempt to add a malicious DTD:

<!DOCTYPE configuration [
  <!ENTITY external SYSTEM "file:///sensitive/file">
]>

If the application's XML parser is configured to process external entities, the XML parser may attempt to resolve the entity.

This demonstrates an important principle:

XML parsing itself is not automatically dangerous, but insecure parser configuration can make XML processing vulnerable.

10. Best Practices for DTD Security

The following practices help reduce DTD-related security risks:

Disable External Entities When Not Required

If the application does not need external entities, they should be disabled.

Disable External DTD Loading When Possible

Applications that do not require external DTDs should prevent the parser from automatically retrieving them.

Use Trusted XML Sources

Avoid accepting arbitrary XML documents from untrusted users whenever possible.

Apply Resource Limits

Limit XML document size, entity expansion, nesting depth, and processing resources.

Keep XML Libraries Updated

Security vulnerabilities can be discovered in XML libraries and parser implementations. Keeping dependencies updated helps reduce exposure to known vulnerabilities.

Validate Input

Applications should validate XML input according to the requirements of the application rather than assuming that every received XML document is safe.

Use Secure Parser Settings

Security settings should be configured at the parser level rather than relying solely on application-level validation.

Conclusion

DTD security is primarily concerned with the way XML parsers handle entities, external resources, and recursive entity expansion. Features such as external entities and entity references were designed to provide flexibility in XML, but they can become security risks when malicious XML is processed without appropriate restrictions.

The most important risks include XML External Entity attacks, excessive entity expansion, denial-of-service attacks, unauthorized file access, and unwanted network requests. Developers should therefore disable unnecessary DTD functionality, particularly external entity and external DTD processing, when handling untrusted XML.

Understanding these security considerations is essential for anyone working with XML and DTDs because a secure XML application depends not only on writing a valid DTD but also on configuring the XML parser to process potentially untrusted documents safely.