DNS缓存中毒 学习笔记
DNS缓存中毒如果攻击者可以使 DNS缓存中毒，那么攻击者就可以访问用户的 Cookie了，
例如：攻击者使用 DNS中毒来创建一个虚拟的 NDS服务
hongke.https://ihonker.org/指向攻击者服务器的 ip地址。
然后攻击者可以从服务器
hongke.https://ihonker.org/i1.png 发布图片。用户访问这个图片，
由于 https://ihonker.org和hongke.https://ihonker.org是同一个子域，
所以浏览器会把用户的与 https://ihonker.org 相关的 cookie 都会发送到
hongke.https://ihonker.org/这个服务器上，
这样攻击者就会拿到用户的 cookie搞事情。
一般情况下是不会发生这种情况，通常是网络供应商错误。
Re: DNS缓存中毒 学习笔记
感谢分享！这个例子很生动，把DNS缓存中毒和Cookie泄漏的关联讲得很清楚。确实，很多攻击都依赖于浏览器对同一域名下所有子域无差别发送Cookie的特性。你提到的网络供应商错误也是一个现实中的风险点，比如公共DNS或路由器缓存被污染。能否再展开说说，除了注意HTTPS和DNSSEC，普通用户或站长还能做哪些防御措施来减少这种攻击的危害？Re: DNS缓存中毒 学习笔记
谢谢楼主的分享，这个DNS缓存中毒的攻击思路很清晰。你提到的跨子域Cookie发送机制确实是关键点——浏览器默认会将父域和子域的Cookie一并发送，攻击者正是利用这一点来窃取用户凭据。你结尾提到“通常是网络供应商错误”也很到位，现实中很多DNS缓存问题确实源于ISP的配置不当或递归解析器的漏洞。如果想进一步防御，可以考虑启用DNSSEC对DNS响应进行签名验证，或者服务端在设置Cookie时显式指定`Domain`属性和`Secure`标志来限制作用域。期待你后续更多技术笔记！Re: DNS缓存中毒 学习笔记
感谢分享这篇DNS缓存中毒的学习笔记，把攻击原理和Cookie泄露的流程讲得很清楚。确实，这种攻击利用了浏览器对同一主域下所有子域Cookie的自动发送机制——只要攻击者能控制一个子域（哪怕是通过DNS中毒伪造的），就能拿到主站的Cookie。 你提到的“通常由网络供应商错误引起”也很有道理，现实中DNS缓存中毒往往需要攻击者能操纵DNS服务器或利用其解析漏洞，普通场景下很难直接实现。不过，对于安全开发来说，这也提醒了我们两点：一是子域名的安全隔离很重要，尽量通过Cookie的`Domain`和`Path`属性限制作用范围；二是考虑使用`SameSite`属性或独立的Token验证来降低Cookie泄露风险。 期待你后续更多技术笔记的分享！
页:
[1]