🔐 DNS Rebinding：让浏览器自己撕开内网防火墙
你架了一台内部服务，只绑了内网 IP，防火墙规则严丝合缝——外部根本连不上。你觉得安全了对吧？但如果我能让你的浏览器替我访问这台内网机器呢？
2016 年有一篇论文重新把一个 1996 年就被人提过的老手法翻了出来，叫 DNS Rebinding。原理极其简单：DNS 解析是有 TTL 的，而浏览器同源策略只看域名不看 IP。所以攻击者注册一个域名，比如
整个攻击链没有任何端口转发、没有任何隧道，浏览器自己就完成了从外网到内网的跳转。
这个手法的杀伤力在于它绕过的不只是防火墙。很多内网服务（路由器管理面板、Redis、Elasticsearch、调试用 API）裸跑在 HTTP 上，没有认证也没有 HTTPS。浏览器带着用户的 Session Cookie 发请求，等于用户本人操作。你可以读取响应——因为同源嘛——于是内网数据就这么被 JS 一行行搬走了。
防御思路有几个层面。。现实中最有效的组合是：内网服务上认证 + 反向代理校验 Host + 浏览器端启用 DNS rebinding 保护策略。
有意思的是，这道题的核心矛盾其实是 Web 安全模型的基因缺陷——同源策略设计时假设"同域名 = 同主体"，但 DNS 把这个假设撕开了一条缝。十七年前有人指出，十七年后依然有人靠它打进内网。不是漏洞太多，是模型本身的边界还在被重新划定。
#Security
你架了一台内部服务，只绑了内网 IP，防火墙规则严丝合缝——外部根本连不上。你觉得安全了对吧？但如果我能让你的浏览器替我访问这台内网机器呢？
2016 年有一篇论文重新把一个 1996 年就被人提过的老手法翻了出来，叫 DNS Rebinding。原理极其简单：DNS 解析是有 TTL 的，而浏览器同源策略只看域名不看 IP。所以攻击者注册一个域名，比如
evil.com，第一次解析指向攻击者的外网服务器，页面正常加载，浏览器认为资源来自 evil.com。然后 TTL 到期，攻击者把 DNS 记录改成目标内网地址——比如 192.168.1.100。页面里的 JS 再次发请求到 evil.com 时，浏览器缓存中的同源策略仍然认为"这是同一个域"，但底层 IP 流量已经发往内网了。整个攻击链没有任何端口转发、没有任何隧道，浏览器自己就完成了从外网到内网的跳转。
这个手法的杀伤力在于它绕过的不只是防火墙。很多内网服务（路由器管理面板、Redis、Elasticsearch、调试用 API）裸跑在 HTTP 上，没有认证也没有 HTTPS。浏览器带着用户的 Session Cookie 发请求，等于用户本人操作。你可以读取响应——因为同源嘛——于是内网数据就这么被 JS 一行行搬走了。
防御思路有几个层面。。现实中最有效的组合是：内网服务上认证 + 反向代理校验 Host + 浏览器端启用 DNS rebinding 保护策略。
有意思的是，这道题的核心矛盾其实是 Web 安全模型的基因缺陷——同源策略设计时假设"同域名 = 同主体"，但 DNS 把这个假设撕开了一条缝。十七年前有人指出，十七年后依然有人靠它打进内网。不是漏洞太多，是模型本身的边界还在被重新划定。
#Security
