防范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时，务必警惕任何可能触发外部资源加载的配置，并对输入内容进行严格的验证。
解决方案
说实话，每次遇到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);// 还有一些其他可能需要考虑的，比如XIncludedbf.setXIncludeAware(false);dbf.setExpandEntityReferences(false); // 这一条也很关键，防止实体扩展
Python的
lxml
库相对来说默认安全一些，但你仍然可以通过
resolve_entities=False
等参数来控制：
from lxml import etreeparser = 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文档中插入恶意构造的外部实体引用时，如果解析器没有正确地限制这种行为，它就会去加载并处理这些外部资源，从而引发一系列安全问题。
为什么危险？因为一旦攻击成功，它能做的事情远不止是“注入一些文本”那么简单。
文件读取（任意文件读取）：这是最常见的利用方式。攻击者可以通过外部实体引用来读取服务器上的任意文件，比如
/etc/passwd
、应用程序的配置文件、源代码等等。想象一下，你的数据库密码、API密钥、甚至用户数据，都可能因此暴露。
<!DOCTYPE foo [ ]>&xxe;
服务器端请求伪造（SSRF）：攻击者可以诱使服务器向内部网络、其他服务或外部网站发起请求。这可以用于探测内部网络结构、攻击内网服务，甚至进行端口扫描。
<!DOCTYPE foo [ ]>&xxe;
拒绝服务（DoS）攻击：十亿笑声攻击（Billion Laughs Attack）：通过定义层层嵌套的实体，让解析器在扩展实体时耗尽内存和CPU资源，导致服务崩溃。
<!DOCTYPE lolz [ ]>&lol9;
参数实体递归：利用参数实体进行递归引用，同样能造成资源耗尽。远程代码执行（RCE）：虽然不常见，但在某些特殊配置下（例如，如果XML解析器与某些协议处理器结合，如PHP的expect协议），XXE可能导致远程代码执行。
这些攻击的威胁级别非常高，因为它直接触及了服务器的底层文件系统和网络能力，一旦被利用，后果不堪设想。
除了禁用DTD，还有哪些额外的防御措施需要考虑？
仅仅禁用DTD或外部实体解析，虽然是治本之策，但作为防御者，我们总得考虑多几层保障，以防万一。毕竟，安全从来不是一劳永逸的。
严格的输入验证和白名单机制：不要仅仅依赖解析器的配置。在XML数据进入解析器之前，对其进行严格的结构和内容验证。如果你的应用只需要处理特定结构的XML，那么就用XML Schema (XSD) 或者Relax NG对其进行验证。更激进一点，如果你知道XML中某些元素或属性不应该包含任何实体引用，可以在解析前用正则表达式或者其他字符串处理方式进行预处理，移除或转义这些潜在的危险字符。白名单总是比黑名单更安全，因为它只允许已知的好东西通过。最小权限原则：运行XML解析服务的用户或进程，应该只拥有完成其任务所需的最小权限。例如，限制其对文件系统的访问权限，限制其网络出站连接的能力。如果解析器不能访问文件系统或外部网络，那么即使XXE被触发，其危害也会大大降低。网络层面的限制：在服务器防火墙层面，限制应用程序服务器对外发起网络请求的能力。如果你的应用不需要访问外部网络，那么就阻止它。这可以有效阻止SSRF攻击，即使XML解析器存在漏洞，也无法通过它来探测或攻击内网。安全审计和日志监控：记录所有XML解析相关的异常和错误。如果检测到可疑的外部实体请求（例如，请求了不应该被访问的文件路径或外部URL），立即触发告警。持续监控日志可以帮助你发现潜在的攻击行为，即使它们没有立即导致系统崩溃。定期更新和打补丁：XML解析库本身也可能存在漏洞。保持你的XML解析库和相关依赖库的最新版本，及时应用安全补丁，这能有效防范已知漏洞的利用。考虑替代方案：如果业务场景允许，重新评估是否真的需要使用XML。JSON、Protobuf等数据格式在很多场景下更轻量、更易于处理，并且通常没有XML那么多复杂的安全陷阱。当然，每种技术都有其适用场景和需要注意的安全点，这只是一个思考方向。
这些措施就像是给你的XML解析器穿上了一层又一层的防弹衣。即便某一层防线被突破，还有其他层来提供保护。
我的应用需要处理一些DTD，如何平衡安全与功能？
好吧，现实总是比理想复杂。有时候，你就是没办法完全禁用DTD，比如，你正在处理一些遗留系统，或者你的业务流程确实依赖于DTD来验证XML的结构。这种情况下，就得在安全性和功能性之间找到一个平衡点。这就像在钢丝上跳舞，每一步都得小心翼翼。
明确且严格地限制外部实体加载：如果不能完全禁用外部实体，那就只能允许加载你明确信任的、极少数的外部实体。这意味着你需要实现一个自定义的实体解析器（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 allowedSystemIds = new HashSet(); // 允许的本地DTD内容，或者从安全位置加载的DTD private final String trustedLocalDtd = ""; // 示例：一个安全的本地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解析和验证。
内容清洗和转义：如果你的XML数据中可能包含用户输入，并且这些输入可能会被解析器处理为DTD内容（例如，通过参数实体），那么在将用户输入插入到XML文档中之前，必须对其进行严格的清洗和转义。确保任何可能被解释为DTD语法或实体引用的字符都被中和掉。
最小化DTD的使用：重新审视你的设计，看看哪些地方可以摆脱DTD。很多时候，XML Schema (XSD) 能够提供比DTD更强大、更安全的验证能力，而且它本身不涉及外部实体解析的复杂性。如果只是简单的结构验证，甚至可以考虑用更轻量的方式（如代码逻辑）进行。
沙箱环境：如果你的应用确实需要处理高度不可信的XML，并且无法完全避免XXE风险，那么考虑将XML解析过程放到一个隔离的沙箱环境中。这个沙箱应该有极度严格的资源限制（CPU、内存、网络、文件系统），即使攻击成功，也无法对主系统造成大的破坏。但这通常需要更复杂的系统架构和运维投入。
总而言之，处理必须使用DTD的场景，核心在于“信任最小化”。只信任那些你明确知道是安全的，并且对其有完全控制的资源。任何不确定的，都一概拒绝。
以上就是XML的DTD实体注入攻击怎么防范？解析时要注意什么？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1430389.html
微信扫一扫 
支付宝扫一扫 
