PayloadsAllTheThings 之 DNS Rebinding 攻击：原理、方法论与防护绕过实战指南

• 网络安全
• 应用安全
• 渗透测试

本文以 DNS Rebinding/README.md 为核心骨架，系统梳理 DNS Rebinding 攻击的完整原理与攻击流程、NCC Group Singularity 框架的使用方法、以及针对常见 DNS 防护措施的三种绕过手法（0.0.0.0 / CNAME / localhost），并结合本仓库 Server Side Request Forgery 与 Headless Browser 章节中的实际案例，给出可直接落地的验证命令与扩展攻击面。读完本文，你将能够：理解浏览器同源策略在 DNS 层面被突破的底层机制、按步骤搭建并执行一次完整的 DNS Rebinding 攻击、以及在有 DNS 防护（如 RFC 1918 私网段过滤）的环境中继续突破。

什么是 DNS Rebinding

DNS Rebinding（DNS 重绑定）攻击的核心是：攻击者控制的域名，其 DNS 解析结果在短时间内从"看似合法的公网 IP"切换为"目标应用的内网/本机 IP"，从而绕过浏览器的同源策略（Same-Origin Policy），让受害者的浏览器能够向目标内网应用发起任意请求，并读取其响应内容。

同源策略规定：只有当协议、域名、端口三者完全一致时，页面中的脚本才能读写另一个源的资源。浏览器在判断"源"时依据的是域名而非其背后的 IP。攻击者正是利用这一点——先让malicious.com解析到公网 IP 加载恶意页面（此时浏览器认为源是malicious.com），随后将该域名重新解析到内网 IP（如192.168.1.1），浏览器再次请求malicious.com时实际连接的是内网目标，但由于 URL 仍是malicious.com，同源策略依然放行，恶意脚本可以自由读取内网服务的响应。

攻击方法论：五阶段完整流程

原文档将一次 DNS Rebinding 攻击拆解为五个阶段，下面逐阶段展开并结合本仓库内容补充可验证细节。

1. 搭建阶段（Setup Phase）

• 注册一个恶意域名（例如malicious.com）；
• 配置一台自定义 DNS 服务器，使其能够将malicious.com解析到不同的 IP 地址（公网 IP 与内网 IP 交替返回）。

在实际测试中，也可以直接使用现成的 DNS Rebinding 服务来免去自建 DNS 服务器的成本。例如本仓库 Server Side Request Forgery/README.md 的 "Bypass Using DNS Rebinding" 一节提到1u.ms这类 DNS rebinding 工具：要实现在1.2.3.4与169.254.169.254（云元数据服务地址）之间轮换，只需使用形如以下格式的域名：

make-1.2.3.4-rebind-169.254-169.254-rr.1u.ms

用nslookup连续查询即可验证轮换效果（两次查询返回不同地址）：

$ nslookup make-1.2.3.4-rebind-169.254-169.254-rr.1u.ms Name: make-1.2.3.4-rebind-169.254-169.254-rr.1u.ms Address: 1.2.3.4 $ nslookup make-1.2.3.4-rebind-169.254-169.254-rr.1u.ms Name: make-1.2.3.4-rebind-169.254-169.254-rr.1u.ms Address: 169.254.169.254

关联延伸：在云场景下，169.254.169.254正是 AWS EC2 元数据服务地址，具体元数据端点列表见 SSRF-Cloud-Instances.md（如http://169.254.169.254/latest/meta-data/iam/security-credentials），DNS Rebinding 常被用作获取该内网元数据的桥梁。

2. 初始受害者交互（Initial Victim Interaction）

• 在malicious.com上创建一个包含恶意 JavaScript 或其他利用机制的网页；
• 通过钓鱼、社会工程或广告投放等方式诱导受害者访问该恶意网页。

3. 初始 DNS 解析（Initial DNS Resolution）

• 当受害者的浏览器访问malicious.com时，会向攻击者的 DNS 服务器查询该域名对应的 IP；
• DNS 服务器先将malicious.com解析为一个看似合法的初始 IP（例如203.0.113.1），让页面正常加载、脚本正常执行。

4. 重绑定到内网 IP（Rebinding to Internal IP）

• 浏览器完成初始请求后，攻击者的 DNS 服务器将malicious.com的解析结果更新为私网或内网 IP（例如192.168.1.1，对应受害者路由器或其他内网设备）；
• 这一步通常通过为初始 DNS 响应设置**极短的 TTL（Time-To-Live）**来实现，强制浏览器在缓存过期后重新发起 DNS 解析，从而拿到更新后的内网 IP。

5. 同源利用（Same-Origin Exploitation）

• 由于浏览器认为后续响应仍来自同一源（malicious.com），同源策略不再构成阻碍；
• 运行在受害者浏览器中的恶意 JavaScript 现在可以向内网 IP 或本机服务（如192.168.1.1、127.0.0.1）发起请求并读取响应，从而绕过同源策略限制。

实战示例：使用 Singularity of Origin

原文档给出的完整落地步骤如下（推荐使用 NCC Group 的 Singularity 框架，其 DNS Rebinding 攻击框架与 Web 客户端详见原文档工具清单）：

1. 注册一个域名；
2. 按官方文档搭建 Singularity of Origin（Setup and Installation）；
3. 根据你的目标编辑autoattackHTML 页面；
4. 在浏览器中访问http://rebinder.your.domain:8080/autoattack.html；
5. 等待攻击完成（通常需要几秒到几分钟）。

补充说明：本仓库 Headless Browser/README.md 的 "DNS Rebinding" 一节记录了针对 Chrome 的一类进阶变体：Chrome 会同时发出A和AAAA两次 DNS 查询，攻击者让AAAA返回合法公网 IPv6、A返回内网 IPv4，Chrome 会优先连接 IPv6；此时关闭 IPv6 监听器，待浏览器回退到 IPv4 连接后，即可从顶层窗口向 iframe 注入脚本窃取内网内容。这说明了 DNS Rebinding 在真实浏览器环境中往往需要结合浏览器自身的解析与回退行为来精细调整。

防护绕过（Protection Bypasses）

大多数 DNS 防护手段的实现方式是：在 DNS 响应进入内网的边界处，拦截包含"不受欢迎 IP 地址"的 DNS 应答包。最常见的是按 RFC 1918 定义的私网地址段进行拦截，即10.0.0.0/8、172.16.0.0/12、192.168.0.0/16。部分防护工具还支持额外拦截localhost（127.0.0.0/8）、本地（内网）网段，甚至0.0.0.0/0全网段。

需要说明的是：这类防护通常默认关闭（disabled by default）。在防护被启用的场景下，NCC Group 在 Singularity 的文档中记录并验证了多种绕过方法，原文档收录了以下三种核心手法。

绕过 1：使用 0.0.0.0

对于拦截 DNS 响应中包含127.0.0.1或127.0.0.0/8的防护规则，可以改用 IP 地址0.0.0.0来访问本机（localhost）。

原理：部分操作系统和 Web 服务会将0.0.0.0视为本机地址（在监听与连接场景下通常等价于回环），而防护规则只匹配127.0.0.0/8网段，0.0.0.0不在拦截范围内，因此可以干净地绕过基于回环网段过滤的规则。

绕过 2：使用 CNAME 记录

对于拦截所有内网 IP 地址的 DNS 防护方案，可以利用DNS CNAME 记录绕过：由于 DNS 响应中只返回一个"内网服务器域名"的 CNAME，而没有直接出现内网 IP 地址，因此针对 IP 地址的过滤规则不会被触发；之后由本地内网 DNS 服务器负责解析该 CNAME，最终仍能到达内网目标。

原文档给出的验证命令（使用dig查询并只显示应答部分）：

$ dig cname.example.com +noall +answer ; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> example.com +noall +answer ;; global options: +cmd cname.example.com. 381 IN CNAME target.local.

可以看到，应答记录中仅包含CNAME target.local.，没有任何内网 IP 字面量，从而绕过基于 IP 的过滤规则，交由内网 DNS 将target.local.解析为实际内网地址。

绕过 3：使用 localhost 作为 CNAME

对于拦截 DNS 响应中包含127.0.0.1的防护规则，可以直接使用 "localhost" 作为 DNS CNAME 记录——响应中不出现任何127.0.0.1的 IP 字面量，而localhost由系统解析器天然映射到回环地址。

$ dig www.example.com +noall +answer ; <<>> DiG 9.11.3-1ubuntu1.15-Ubuntu <<>> example.com +noall +answer ;; global options: +cmd localhost.example.com. 381 IN CNAME localhost.

绕过思路小结

仓库内相关攻击面：DNS Rebinding 与其他漏洞的结合

DNS Rebinding 的价值往往体现在与其他攻击面联动时，本仓库在多个章节收录了相关案例：

• SSRF 场景：Server Side Request Forgery/README.md 在 "Bypass Using DNS Rebinding" 一节中将 DNS Rebinding 作为 SSRF 的绕过手段，即"创建一个在两个 IP 之间切换的域名"，从而让服务端发起的请求先通过外网校验、再落到内网目标（如云元数据服务169.254.169.254）。这与其 Cloud 章节（SSRF-Cloud-Instances.md）中的元数据服务端点配合，可用于读取 IAM 临时凭证。
• Headless Browser 场景：Headless Browser/README.md 记录了在无头浏览器自动化测试中利用 Chrome 的A/AAAA双查询与 IPv6 优先策略进行 DNS Rebinding 的细节，并提醒 Chrome 默认会拦截一批"已知端口"，且默认阻止除 localhost 之外的本地网络地址访问。
• IP 混淆辅助：Server Side Request Forgery/Files/ip.py 提供了多种 IP 编码与绕过验证脚本（如使用2852039166十进制整数形式等价于169.254.169.254，或0xa9fea9fe十六进制形式），可在 DNS 防护之外进一步混淆目标地址。

检测与防护建议

结合原文档中关于防护机制的描述，给出以下对抗要点：

1. 在 DNS 边界过滤：拦截进入内网的 DNS 响应中包含私网 IP（RFC 1918）、127.0.0.0/8、0.0.0.0等非公网地址的应答，并注意 CNAME 类型的间接解析同样需要审查（内网域名不能被外部 DNS 权威解析）。
2. DNS 固定（DNS Pinning）：在浏览器或代理层面将域名首次解析的 IP 固定，禁止后续解析结果变更，可从根本上阻止域名"换 IP"；但需注意浏览器策略差异以及公网 CDN 场景下轮询解析的误伤。
3. 服务端防护：内网与云元数据服务（169.254.169.254）应通过防火墙、Host 头校验、鉴权令牌（如 AWS 元数据服务的 IMDSv2 会话令牌）等方式限制访问，降低即使被重绑定也能读取敏感信息的影响面。
4. 用户侧意识：对于安全测试场景，应在隔离环境（如专用测试浏览器或虚拟机）中执行 DNS Rebinding 验证，避免影响真实生产内网。

结语

DNS Rebinding 是 Web 安全测试中"浏览器即代理"思路的典型代表：它通过操纵域名解析结果，在合法的同源关系内完成了对同源策略的突破。原文档给出了从原理、工具、五阶段方法论到三种防护绕过手法的完整闭环，本文在此基础上结合本仓库的 SSRF、Headless Browser 与云实例章节，补充了可复现的轮换域名验证命令、Chrome 解析行为细节及联动攻击面。在实战中，建议优先使用 Singularity 框架完成自动化验证，再按目标环境的防护强度逐步尝试 0.0.0.0、CNAME、localhost 等绕过手段。

本文事实依据：核心原理、方法论、绕过手法与验证命令均来自 DNS Rebinding/README.md；SSRF 联动案例与1u.ms轮换域名验证命令来自 Server Side Request Forgery/README.md（"Bypass Using DNS Rebinding" 一节）；Chrome 双 DNS 查询与 IPv6 回退细节来自 Headless Browser/README.md；云元数据服务地址与端点来自 SSRF-Cloud-Instances.md。

• 网络安全
• 应用安全
• 渗透测试