DNS pinning 不能防止复杂的 DNS 重新绑定攻击。

考虑一个攻击者在其 Web 服务器前面设置防火墙的场景。您请求他们的网站，attacker.com，这会导致 DNS 查询返回他们的 IP 地址。DNS 结果的 TTL（生存时间）为 1 秒。通常，这意味着浏览器应该在 1 秒后发出另一个 DNS 请求，但是，DNS 固定指示浏览器忽略 TTL 并添加一些时间单位（比如一小时）。所以现在，您的浏览器在 1 小时 1 秒内不会对该主机名进行另一个 DNS 查询。在 DNS 查询完成后，您的 HTTP 请求将被发送，攻击者将使用 javascript 代码发回您请求的网站，这将发起攻击。

现在，攻击者的 Javascript 设置了一个 AJAX 请求，该请求在触发前等待两秒钟。然后它会自动再次请求攻击者网站上的一些资源。但是，请求失败。这是因为攻击者已经设置了防火墙规则来阻止你的浏览器请求。现在我们处于以下状态：

1. 第一次 DNS 请求时 TTL 已过期，但 DNS 固定仍然有效
2. 您通过他们的 JS AJAX 调用向攻击者的网站发出请求
3. 请求被攻击者的防火墙丢弃

尽管您使用的是 DNS 固定，这三件事将导致您的 Web 浏览器发送另一个 DNS 查询。实际上，攻击者通过使用防火墙并在 TTL 之外发送第二个请求，轻松击败了您的 DNS 固定策略。DNS pinning 不是一种有效的策略，因为有很多正当的理由可以导致某人的服务器宕机；如果有另一个 DNS 记录将解析到正确的机器（例如，在服务器迁移、停机等情况下），您的浏览器将被迫进行第二次 DNS 查询。基本上，您的浏览器无法知道它是否真的在这里受到了攻击；据它所知，服务器已合法关闭，因此它必须发出另一个 DNS 请求。

那么......为什么有第二个DNS请求很重要？

攻击者通常使用第二个 DNS 请求来为 DNS 记录返回错误的 IP 地址。浏览器具有所谓的“同源”策略，可防止网页请求它们不拥有的资源。基本上相同来源的工作方式是它说http://hostname.com只能请求http://hostname.com. 但它实际上使用 hostname.com 的 IP 地址，而不是人类可读的主机名本身。因此，在 DNS 重新绑定攻击中，当您的浏览器进行我之前描述的第二次 DNS 查询时，攻击者将在 DNS 查询结果中返回一个“假”IP 地址。然后你的浏览器会认为，例如，IP 地址 1.1.1.1 属于攻击者.com，即使它确实属于 google.com。这允许攻击者利用浏览器的同源策略；现在攻击者的 javascript 可以通过 AJAX 从 google.com 请求内容。此外，他们可以读取和设置 cookie 和其他恶意内容。这通过欺骗浏览器信任返回的第二个 DNS 记录来利用同源策略。现在浏览器认为 hostname.com 与 IP 地址 1.1.1.1 相关联，即使它确实不是 吨。浏览器有什么用？DNS 没有内置这种身份验证。:(

防止 DNS 重新绑定攻击

有很多方法可以防止它，我很确定现代浏览器已经实现了针对这些攻击的保护。防止它的一种简单方法（作为 Web 所有者）是检查请求的 HTTP 主机标头。例如，如果您是 google.com，那么您会收到一个请求，但主机标头仍会显示攻击者.com。显然，这不是您的域的一部分，因此您可以通过丢弃请求来防止攻击。为什么有人要开始这样做？好吧，广告中的点击欺诈。一次从多台机器上抓取搜索引擎。从公司内部网络上的网站窃取有价值的数据。等等。

如果您想考虑可以在浏览器中执行的全部内容，那么仅浏览器执行 DNS 固定是不够的。Flash 和 Java 等浏览器插件可以访问套接字，这意味着它们很可能自己执行 DNS 查询，如果它们不实现自己的 DNS 固定策略，那么浏览器仍然会受到代理的攻击。有关Jackson 等人的“保护浏览器免受 DNS 重新绑定攻击”，请参阅http://crypto.stanford.edu/dns/或 Google。了解更多详情。

我将尝试在我链接到的示例攻击的帮助下回答我自己的问题。欢迎反馈和评论，因为我不确定这个答案的正确性。

是的，DNS pinning 可以防止所描述的攻击，尽管它不需要使情况完全安全。想象一下：

1. 最初，药师安排受害者对 www.good.com 的 DNS 查询解析为药师的 IP 地址 6.6.6.6。
2. 然后，当受害者访问 www.good.com 时，药师返回一个包含恶意 Javascript 的木马文档和一个引用 www.good.com/homepage 的 iframe。药剂师还确保 Cache-Control 标头指定了一个非常高的 max-age 值。
3. 然后，药师将 www.good.com 的 DNS 条目更新为 Good 合法服务器的 IP 地址，并拒绝来自受害者的后续连接。
4. 这会导致受害者的浏览器为 www.good.com 更新其 DNS 条目，由于 DNS 固定，浏览器将不允许这样做。
5. DNS pinning 将导致 iframe 源从 pharmer 的 IP 地址 (6.6.6.6/homepage) 中获取。
6. 该请求被药剂师的服务器拒绝，用户会看到一个错误。

一段时间后，当受害者再次打开浏览器并尝试访问 www.good.com

1. 无论 DNS 记录如何，包括恶意 Javascript，页面的缓存版本都会加载到浏览器中。
2. iframe将再次加载，因为 Cache-Control 标头不适用于 iframe 中的内容（此声明需要一些备份）。
3. iframe 内容将指向正确的服务器，因为 DNS 记录是固定的
4. Good 的合法主页是在 iframe 中加载的。

有哪些未成功防御的攻击场景示例？

除了上述场景之外，在 Mozilla 的 Bugzilla 站点上的评论中给出了一个不同类型的示例攻击场景，涉及 DNS 缓存问题。

DNS TTL 信息不是单个应用程序应该决定它不想遵守的东西。

有一些讨论认为当前的行为是一个“安全”问题。拒绝遵守 DNS 查找中的 TTL 参数是一个很大的安全漏洞，甚至可能更大。使用缓存的、过期的 DNS 查找（例如对于那些使用动态 DNS 服务的用户）最终会将错误的信息发送到错误的服务器，可能是 e-vil 服务器。

可能的情况：

1. 我的家庭服务器使用 DHCP，接收到动态 IP 地址 12.13.14.15
2. 我注册动态服务 myhome.dyndns.org 指向 12.13.14.15
3. 用户 Alice 使用 Mozilla 访问我的网站，并开始交易。
4. 我的 DHCP 租约到期，我获得了一个新的 IP 地址 12.200.200.200
5. 我的服务器检测到更改并自动将 myhome.dyndns.org 注册到 12.200.200.200
6. 我的旧 DHCP 地址 12.13.14.15 被分配给 Bob Evil 的计算机。
7. Alice 在 Mozilla 中完成了一个 Web 表单的填写并提交。Mozilla 错误地使用了缓存的 IP 地址 12.13.14.15，并将数据错误地发送到 Bob Evil 的计算机。

这实际上发生在我身上。即使我已经注册了一个新的 IP 地址，我最终还是访问了其他人的 DSL 路由器（如果他们没有设置网站）而不是我自己的 Mozilla 服务器。