XXE漏洞源于XML解析器处理外部实体时的配置不当，攻击者可借此读取敏感文件、发起SSRF或DoS攻击；防范核心是禁用外部实体解析，如Java中设置安全特性、PHP调用libxml_disable_entity_loader、Python使用defusedxml库、.NET配置XmlReaderSettings禁止DTD和外部解析，同时结合输入验证与最小权限原则降低风险。
XML外部实体引用（XXE）在绝大多数情况下都是不安全的，它是一个严重的、且被广泛利用的安全漏洞，可能导致敏感信息泄露、拒绝服务，甚至服务器端请求伪造（SSRF）和远程代码执行。
XML外部实体引用（XXE）本身并不是XML标准设计上的“错误”，而是XML解析器在处理外部引用时，如果配置不当，会成为攻击者利用的通道。在我看来，这更像是一种“善意”功能的“恶意”滥用。当一个XML解析器被指示去处理一个XML文档，并且该文档中包含了对外部资源的引用（比如文件路径、URL），如果解析器没有禁用对这些外部实体的解析，它就会尝试去获取并嵌入这些资源的内容。
想象一下，你给一个系统喂了一个看起来人畜无害的XML，但里面悄悄藏着一行指令，让服务器去读取它本地的
/etc/passwd
XML外部实体引用（XXE）攻击是如何发生的？ XXE攻击的发生，本质上是攻击者利用了XML解析器在处理XML文档时，解析并加载外部资源的能力。攻击者会精心构造一个恶意的XML文档，其中包含对外部实体的引用。当受攻击的应用程序接收并解析这个恶意XML时，如果其底层的XML解析器没有禁用外部实体解析功能，就会按照攻击者的指示去获取指定的外部资源。
举个例子，攻击者可能会在XML文档的
DOCTYPE
<?xml version="1.0"?> <!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]> <data> <user>&xxe;</user> </data>
当应用程序解析这个XML时，如果它允许外部实体解析，那么
&xxe;
/etc/passwd
user
除了文件读取，攻击者还可以通过引用远程URL来尝试服务器端请求伪造（SSRF），或者通过引用大量内部文件甚至递归引用自身来发起拒绝服务（DoS）攻击，让服务器资源耗尽。更隐蔽的是“盲XXE”攻击，即使服务器没有直接返回实体内容，攻击者也可以通过带外（Out-of-Band）通道（例如，让服务器向攻击者控制的服务器发起HTTP请求或DNS查询）来窃取数据或确认漏洞的存在。这种攻击往往发生在Web服务接收XML数据作为输入（如SOAP请求、RESTful API的XML体）的场景中，使得原本看似正常的业务交互，成了数据泄露的入口。
如何有效防范XML外部实体注入攻击？ 防范XXE攻击的核心原则，同时也是最直接有效的方法，就是禁用XML解析器对外部实体的解析功能。这并非XML标准本身的问题，而是我们在使用XML解析库时，必须主动去配置的安全性考量。以下是一些主流编程语言和框架的具体防范措施：
Java: 在Java中，不同的XML解析器有不同的配置方法。通常，你需要设置特性来禁用DTD和外部实体：
DocumentBuilderFactory
SAXParserFactory
DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
dbf.setFeature(XMLConstants.FEATURE_SECURE_PROCESSING, true); // 启用安全处理
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true); // 禁用DOCTYPE声明
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false); // 禁用外部通用实体
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false); // 禁用外部参数实体
dbf.setXIncludeAware(false); // 禁用XInclude
dbf.setExpandEntityReferences(false); // 禁用实体引用扩展XMLInputFactory
XMLInputFactory xif = XMLInputFactory.newInstance(); xif.setProperty(XMLInputFactory.IS_SUPPORTING_EXTERNAL_ENTITIES, false); xif.setProperty(XMLInputFactory.SUPPORT_DTD, false);
PHP: 对于基于libxml的PHP函数（如
simplexml_load_string()
DOMDocument::loadXML()
libxml_disable_entity_loader(true); // 在解析XML之前调用
Python: Python的标准库XML解析器（如
xml.etree.ElementTree
lxml
defusedxml
defusedxml
from defusedxml.lxml import parse tree = parse(xml_file)
lxml
from lxml import etree parser = etree.XMLParser(resolve_entities=False, no_network=True) tree = etree.parse(xml_file, parser)
.NET: 在.NET中，使用
XmlReader
XmlReaderSettings
XmlReaderSettings settings = new XmlReaderSettings();
settings.DtdProcessing = DtdProcessing.Prohibit; // 禁止DTD处理
settings.XmlResolver = null; // 禁用外部资源解析
using (XmlReader reader = XmlReader.Create(xmlStream, settings))
{
// 解析XML
}除了上述代码层面的防护，还有一些通用的安全实践：
XXE漏洞与服务器端请求伪造（SSRF）之间有什么联系？ XXE漏洞与服务器端请求伪造（SSRF）之间存在着一种紧密的、有时甚至是致命的联系。在我看来，XXE常常是实现SSRF攻击的一种非常有效且隐蔽的手段。
首先，我们简要回顾一下SSRF：服务器端请求伪造（SSRF）是一种攻击，攻击者通过操纵服务器端应用程序，使其向攻击者指定的任意URL发起请求。这些请求由服务器发起，而非攻击者的浏览器，因此可以绕过客户端的访问限制，访问通常受保护的内部网络资源、本地文件，甚至可以对内网服务进行端口扫描或利用其他漏洞。
那么，XXE是如何与SSRF关联起来的呢？当一个XML解析器在处理一个外部实体引用时，如果这个引用指向一个URL（例如
http://internal-service/api
gopher://
举个例子，攻击者可以构造如下的XXE payload：
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://192.168.1.100/admin"> ]> <data>&xxe;</data>
如果服务器解析了这个XML，它就会尝试去访问
http://192.168.1.100/admin
192.168.1.100
gopher://
因此，XXE漏洞的危害远不止于简单的文件读取。它为攻击者提供了一个强大的“代理”能力，让服务器充当攻击者的眼睛和手，去探索和攻击通常被防火墙保护的内部网络。在我看来，这种能突破网络边界的特性，正是XXE被列为高危漏洞的重要原因之一，因为它将原本局限于应用层面的风险，迅速扩展到了整个网络基础设施。
以上就是XML外部实体引用安全吗？的详细内容，更多请关注php中文网其它相关文章！
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移，垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是，许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号
394
收藏
