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漏洞产生的温床。这种默认开启、但却充满风险的特性，着实让人头疼。
XML外部实体引用（XXE）攻击是如何发生的？XXE攻击的发生，本质上是攻击者利用了XML解析器在处理XML文档时，解析并加载外部资源的能力。攻击者会精心构造一个恶意的XML文档，其中包含对外部实体的引用。当受攻击的应用程序接收并解析这个恶意XML时，如果其底层的XML解析器没有禁用外部实体解析功能，就会按照攻击者的指示去获取指定的外部资源。
举个例子，攻击者可能会在XML文档的
DOCTYPE
声明中，定义一个指向服务器本地文件系统路径的实体，比如：
<!DOCTYPE foo [ ]> &xxe;
当应用程序解析这个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); // 禁用XIncludedbf.setExpandEntityReferences(false); // 禁用实体引用扩展
XMLInputFactory
(StAX):
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
库，它提供了安全的XML解析器替代品。
from defusedxml.lxml import parsetree = parse(xml_file)
lxml
:
from lxml import etreeparser = 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}
除了上述代码层面的防护，还有一些通用的安全实践：
输入验证： 对所有接收到的XML输入进行严格的结构和内容验证。不要盲目信任任何来自外部的XML数据。Web应用防火墙（WAF）： WAF可以作为一道额外的防线，帮助检测并拦截已知的XXE攻击模式，但它不是根本解决方案，不应完全依赖。最小权限原则： 运行应用程序的用户和进程，应只拥有完成其任务所需的最小权限，这可以限制XXE攻击成功后的潜在危害。
XXE漏洞与服务器端请求伪造（SSRF）之间有什么联系？XXE漏洞与服务器端请求伪造（SSRF）之间存在着一种紧密的、有时甚至是致命的联系。在我看来，XXE常常是实现SSRF攻击的一种非常有效且隐蔽的手段。
首先，我们简要回顾一下SSRF：服务器端请求伪造（SSRF）是一种攻击，攻击者通过操纵服务器端应用程序，使其向攻击者指定的任意URL发起请求。这些请求由服务器发起，而非攻击者的浏览器，因此可以绕过客户端的访问限制，访问通常受保护的内部网络资源、本地文件，甚至可以对内网服务进行端口扫描或利用其他漏洞。
那么，XXE是如何与SSRF关联起来的呢？当一个XML解析器在处理一个外部实体引用时，如果这个引用指向一个URL（例如
http://internal-service/api
，或者一个
gopher://
协议的URL），并且解析器允许外部实体解析，那么解析器就会以服务器的身份去尝试获取这个URL的内容。这正是SSRF攻击的核心机制：攻击者通过XML文档，诱导服务器去请求一个外部或内部资源。
举个例子，攻击者可以构造如下的XXE payload：
<!DOCTYPE foo [ ]>&xxe;
如果服务器解析了这个XML，它就会尝试去访问
http://192.168.1.100/admin
。如果
192.168.1.100
是服务器内网中的一台主机，攻击者就成功地利用了XXE漏洞，实现了对内网资源的SSRF攻击。这种方式可以用于：
探测内网服务： 尝试访问内网IP地址和端口，判断哪些服务是开放的。访问内部API： 调用只有内网才能访问的敏感管理接口。读取敏感文件： 如果内网服务返回的文件内容是XML格式，XXE甚至可以链式利用。利用其他协议： 通过
gopher://
协议，可以实现更复杂的攻击，例如向内网数据库发送请求、执行SMTP命令等。
因此，XXE漏洞的危害远不止于简单的文件读取。它为攻击者提供了一个强大的“代理”能力，让服务器充当攻击者的眼睛和手，去探索和攻击通常被防火墙保护的内部网络。在我看来，这种能突破网络边界的特性，正是XXE被列为高危漏洞的重要原因之一，因为它将原本局限于应用层面的风险，迅速扩展到了整个网络基础设施。
以上就是XML外部实体引用安全吗？的详细内容，更多请关注php中文网其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1430718.html
微信扫一扫 
支付宝扫一扫 
