XML的DTD实体注入攻击怎么防范？解析时要注意什么？（时要.注入.实体.解析.防范...）

wufei123 发布于 2025-08-29 阅读（4）
防范XML的DTD实体注入攻击最核心的策略是禁用外部实体解析。具体做法包括在XML解析器中关闭外部实体加载功能，如Java中通过设置SAXParserFactory和DocumentBuilderFactory的特性禁用外部实体、PHP中使用LIBXML_NOENT和LIBXML_NONET选项、Python的lxml库设置no_network等。同时应禁止DOCTYPE声明以防止XXE攻击利用。此外需对输入XML进行严格验证，使用白名单机制限制协议和主机访问，结合最小权限原则、网络访问控制、日志监控与安全审计，并优先考虑用JSON等更安全的数据格式替代XML。若业务必须使用DTD，则应实现自定义实体解析器，仅允许加载可信的本地或指定路径的DTD文件，避免网络请求，预加载并验证DTD内容，限制实体扩展，防止恶意构造导致文件读取、SSRF、DoS等高危风险。

xml的dtd实体注入攻击怎么防范？解析时要注意什么？

防范XML的DTD实体注入攻击，最核心的策略就是禁用外部实体解析功能，或者至少对其进行严格的限制。解析XML时，务必警惕任何可能触发外部资源加载的配置，并对输入内容进行严格的验证。

解决方案

说实话，每次遇到XML解析的安全问题，我脑子里第一个蹦出来的念头就是“能不用XML就不用XML，非用不可就把它管得死死的”。对于DTD实体注入，也就是我们常说的XXE（XML External Entity）攻击，解决方案其实挺直接的：关掉那些可能让你引火烧身的配置。

具体来说，这通常意味着在你的XML解析器配置中，明确地禁用外部实体解析。不同的语言和库有不同的做法，但原理都一样。

比如，在Java里，如果你用的是JAXP（比如DOM或SAX解析器），你需要设置一些特性：

// 对于SAX解析器
SAXParserFactory spf = SAXParserFactory.newInstance();
spf.setFeature("http://xml.org/sax/features/external-general-entities", false);
spf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
spf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); // 禁用DOCTYPE声明
// 对于DOM解析器
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
// 还有一些其他可能需要考虑的，比如XInclude
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false); // 这一条也很关键，防止实体扩展

Python的

lxml
库相对来说默认安全一些，但你仍然可以通过
resolve_entities=False
等参数来控制：
from lxml import etree
parser = etree.XMLParser(no_network=True, dtd_validation=False, load_dtd=False)
# 或者更严格地控制
# parser = etree.XMLParser(resolve_entities=False, no_network=True)
tree = etree.fromstring(xml_data, parser)

PHP的

libxml_disable_entity_loader(true);
是一个全局性的设置，它会禁用所有libxml的外部实体加载，通常在程序启动时就应该设置。但要注意，这个函数自PHP 8.0.0起已被废弃，因为它的副作用太大了。现在推荐的做法是在具体的XML加载函数中传递
LIBXML_NOENT
或
LIBXML_NONET
等选项来禁用。
// 废弃但常见的旧做法
// libxml_disable_entity_loader(true);

// 推荐的新做法，针对具体的XML加载
$doc = new DOMDocument();
// LIBXML_NOENT 禁用实体替换，防止XXE
// LIBXML_NONET 禁用网络访问，防止外部DTD/Schema加载
$doc->loadXML($xml_string, LIBXML_NOENT | LIBXML_NONET);

除了代码层面的禁用，更根本的是对所有传入的XML数据进行严格的输入验证。不要盲目相信任何外部输入，即使它声称是“合法”的XML。

什么是DTD实体注入攻击？它为何如此危险？

DTD实体注入，本质上是攻击者利用XML解析器在处理文档类型定义（DTD）时，对外部实体引用处理不当而进行的一种攻击。简单来说，XML允许你定义“实体”，这些实体可以是内部文本，也可以引用外部资源。当攻击者在XML文档中插入恶意构造的外部实体引用时，如果解析器没有正确地限制这种行为，它就会去加载并处理这些外部资源，从而引发一系列安全问题。

为什么危险？因为一旦攻击成功，它能做的事情远不止是“注入一些文本”那么简单。

  1. 文件读取（任意文件读取）：这是最常见的利用方式。攻击者可以通过外部实体引用来读取服务器上的任意文件，比如
    /etc/passwd
    、应用程序的配置文件、源代码等等。想象一下，你的数据库密码、API密钥、甚至用户数据，都可能因此暴露。
    <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<root>&xxe;</root>
  2. 服务器端请求伪造（SSRF）：攻击者可以诱使服务器向内部网络、其他服务或外部网站发起请求。这可以用于探测内部网络结构、攻击内网服务，甚至进行端口扫描。
    <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://internal-service/admin"> ]>
<root>&xxe;</root>
  3. 拒绝服务（DoS）攻击：
    • 十亿笑声攻击（Billion Laughs Attack）：通过定义层层嵌套的实体，让解析器在扩展实体时耗尽内存和CPU资源，导致服务崩溃。
      <!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol2 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
  <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
  <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
  <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
  <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
  <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<lolz>&lol9;</lolz>
    • 参数实体递归：利用参数实体进行递归引用，同样能造成资源耗尽。
  4. 远程代码执行（RCE）：虽然不常见，但在某些特殊配置下（例如，如果XML解析器与某些协议处理器结合，如PHP的expect协议），XXE可能导致远程代码执行。

这些攻击的威胁级别非常高，因为它直接触及了服务器的底层文件系统和网络能力，一旦被利用，后果不堪设想。

除了禁用DTD，还有哪些额外的防御措施需要考虑？

仅仅禁用DTD或外部实体解析，虽然是治本之策，但作为防御者，我们总得考虑多几层保障，以防万一。毕竟，安全从来不是一劳永逸的。

  1. 严格的输入验证和白名单机制：不要仅仅依赖解析器的配置。在XML数据进入解析器之前，对其进行严格的结构和内容验证。如果你的应用只需要处理特定结构的XML，那么就用XML Schema (XSD) 或者Relax NG对其进行验证。更激进一点，如果你知道XML中某些元素或属性不应该包含任何实体引用，可以在解析前用正则表达式或者其他字符串处理方式进行预处理，移除或转义这些潜在的危险字符。白名单总是比黑名单更安全，因为它只允许已知的好东西通过。
  2. 最小权限原则：运行XML解析服务的用户或进程，应该只拥有完成其任务所需的最小权限。例如，限制其对文件系统的访问权限，限制其网络出站连接的能力。如果解析器不能访问文件系统或外部网络，那么即使XXE被触发，其危害也会大大降低。
  3. 网络层面的限制：在服务器防火墙层面，限制应用程序服务器对外发起网络请求的能力。如果你的应用不需要访问外部网络，那么就阻止它。这可以有效阻止SSRF攻击，即使XML解析器存在漏洞，也无法通过它来探测或攻击内网。
  4. 安全审计和日志监控：记录所有XML解析相关的异常和错误。如果检测到可疑的外部实体请求（例如，请求了不应该被访问的文件路径或外部URL），立即触发告警。持续监控日志可以帮助你发现潜在的攻击行为，即使它们没有立即导致系统崩溃。
  5. 定期更新和打补丁：XML解析库本身也可能存在漏洞。保持你的XML解析库和相关依赖库的最新版本，及时应用安全补丁，这能有效防范已知漏洞的利用。
  6. 考虑替代方案：如果业务场景允许，重新评估是否真的需要使用XML。JSON、Protobuf等数据格式在很多场景下更轻量、更易于处理，并且通常没有XML那么多复杂的安全陷阱。当然，每种技术都有其适用场景和需要注意的安全点，这只是一个思考方向。

这些措施就像是给你的XML解析器穿上了一层又一层的防弹衣。即便某一层防线被突破，还有其他层来提供保护。

我的应用需要处理一些DTD，如何平衡安全与功能？

好吧，现实总是比理想复杂。有时候，你就是没办法完全禁用DTD，比如，你正在处理一些遗留系统，或者你的业务流程确实依赖于DTD来验证XML的结构。这种情况下，就得在安全性和功能性之间找到一个平衡点。这就像在钢丝上跳舞，每一步都得小心翼翼。

  1. 明确且严格地限制外部实体加载：如果不能完全禁用外部实体，那就只能允许加载你明确信任的、极少数的外部实体。这意味着你需要实现一个自定义的实体解析器（Custom Entity Resolver）。

    • 白名单协议和主机：你的自定义解析器应该只允许
      file:///
      协议访问特定路径下的文件（比如，只允许访问
      classpath
      下的DTD文件），或者只允许
      http(s)://
      协议访问你明确列出的、受信任的域名。任何不在白名单内的请求都应该被拒绝。
    • 避免网络访问：尽可能地，预加载所有需要的DTD文件到本地，然后解析器只从本地文件系统加载。这样可以避免在解析过程中发起任何外部网络请求。
    • 严格验证DTD内容：即使是信任的DTD文件，也应该对其内容进行安全审计，确保它们本身没有包含恶意引用或可能导致问题的结构。

    以Java为例，你可以实现

    org.xml.sax.EntityResolver
    接口：
    import org.xml.sax.EntityResolver;
import org.xml.sax.InputSource;
import java.io.IOException;
import java.io.StringReader;
import java.net.URI;
import java.util.HashSet;
import java.util.Set;

public class SecureEntityResolver implements EntityResolver {

    private final Set<String> allowedSystemIds = new HashSet<>();
    // 允许的本地DTD内容，或者从安全位置加载的DTD
    private final String trustedLocalDtd = "<!ENTITY % xxe SYSTEM \"no.dtd\">"; // 示例：一个安全的本地DTD

    public SecureEntityResolver() {
        // 明确允许的外部DTD的SYSTEM ID
        // 比如，你有一个内部的DTD服务，其URL是固定的
        allowedSystemIds.add("http://your-internal-dtd-server/schema/my_trusted_dtd.dtd");
        // 也可以允许特定的本地文件路径，但要非常小心
        // allowedSystemIds.add("file:///path/to/your/trusted/local.dtd");
    }

    @Override
    public InputSource resolveEntity(String publicId, String systemId) throws IOException {
        System.out.println("Attempting to resolve entity: publicId=" + publicId + ", systemId=" + systemId);

        // 1. 优先处理内部或已知安全DTD
        if (systemId != null && systemId.contains("your-internal-dtd-identifier")) { // 假设你有个内部标识
            return new InputSource(new StringReader(trustedLocalDtd));
        }

        // 2. 检查白名单
        if (systemId != null && allowedSystemIds.contains(systemId)) {
            // 如果在白名单内，可以尝试加载。但最好是从本地缓存加载，而不是直接发起网络请求
            // 实际生产中，这里应该有更复杂的逻辑来安全地获取DTD内容
            System.out.println("Allowed systemId: " + systemId + ", attempting to load.");
            // 警告：直接从URL加载仍然有风险，最好是预先下载到本地
            // return new InputSource(systemId); // 这样做仍然危险！
            // 更安全的做法是：从本地文件系统加载预先验证过的DTD
            // return new InputSource(new FileInputStream("/path/to/pre_validated_dtd.dtd"));
        }

        // 3. 拒绝所有其他外部实体加载
        System.err.println("Blocked unauthorized entity resolution attempt for systemId: " + systemId);
        // 返回一个空的InputSource或者抛出异常，阻止加载
        return new InputSource(new StringReader("")); // 返回空字符串，避免加载任何内容
        // 或者抛出异常
        // throw new IOException("Unauthorized external entity resolution attempt.");
    }
}

// 在解析器中使用
// SAXParserFactory spf = SAXParserFactory.newInstance();
// SAXParser saxParser = spf.newSAXParser();
// saxParser.setProperty("http://xml.org/sax/properties/external-general-entities", new SecureEntityResolver()); // 这不是设置属性的方式
// 实际应该是这样：
// XMLReader reader = saxParser.getXMLReader();
// reader.setEntityResolver(new SecureEntityResolver());

    请注意，上面的Java代码是一个概念性的示例，实际生产环境的

    EntityResolver
    实现会更复杂，需要考虑缓存、性能、以及更严格的URI解析和验证。

  2. 内容清洗和转义：如果你的XML数据中可能包含用户输入，并且这些输入可能会被解析器处理为DTD内容（例如，通过参数实体），那么在将用户输入插入到XML文档中之前，必须对其进行严格的清洗和转义。确保任何可能被解释为DTD语法或实体引用的字符都被中和掉。

  3. 最小化DTD的使用：重新审视你的设计，看看哪些地方可以摆脱DTD。很多时候，XML Schema (XSD) 能够提供比DTD更强大、更安全的验证能力，而且它本身不涉及外部实体解析的复杂性。如果只是简单的结构验证，甚至可以考虑用更轻量的方式（如代码逻辑）进行。

  4. 沙箱环境：如果你的应用确实需要处理高度不可信的XML，并且无法完全避免XXE风险，那么考虑将XML解析过程放到一个隔离的沙箱环境中。这个沙箱应该有极度严格的资源限制（CPU、内存、网络、文件系统），即使攻击成功，也无法对主系统造成大的破坏。但这通常需要更复杂的系统架构和运维投入。

总而言之，处理必须使用DTD的场景，核心在于“信任最小化”。只信任那些你明确知道是安全的，并且对其有完全控制的资源。任何不确定的，都一概拒绝。

以上就是XML的DTD实体注入攻击怎么防范？解析时要注意什么？的详细内容，更多请关注知识资源分享宝库其它相关文章！

标签:  时要 注入 实体 

相关阅读

发表评论:

◎欢迎参与讨论，请在这里发表您的看法、交流您的观点。

最近发表

标签列表