安全客点评
思路挺新颖的，虽然这种防护有一定的局限性，比如攻击者用IP替代域名就绕过了，但是可以通过文中提及的XSS DNS防护方式了解到企业业务中有哪些WEB服务的XSS点正在被利用，方便排查，而且该防护措施部署上也不是很复杂。
前言
对于一个大的企业来说，要完全杜绝某一类型的漏洞是很难的，特别是 XSS 这种乍一看危害不大但是实际上影响面比较广，而且触发点相对来说比较多的漏洞。相关案例乌云上很多，有兴趣的可以找乌云镜像站看看。XSS 的利用在 XSS Platform 出现之后就变得简单了，给页面挂上一个 JS，然后剩下的全都交给 XSS Platform 去做，结果也从那里获取，so easy，流程图如下。
而很多人为了图方便，并没有自己搭建私有 XSS Platform，且不说这里存在漏洞泄漏的可能，免费公共的 XSS Platform 往往就那么几个，域名一般也不会变动，这里给了一种防护的思路。
XSS DNS 防护
如标题所说，XSS DNS 防护，是因为在企业网络中发起的 DNS 查询是可以由企业自己的 DNS 服务器自由控制的，所以对于这种暴露的 XSS Platform 只要收集一下把这些域名都 block 掉就行了，这样，企业网络的 XSS 就少一些了。但是 XSS 并没有自己消失只是无法触发了而已，这时稍做修改就能把测试者的 XSS “偷” 过来，还是上面那个图。
因为 DNS 是递归查询的，所以如果企业网络的 DNS 存在 evil.com 的记录，那么这一条 DNS Query 就永远不会递归到 evil.com 域名 NS 记录的 DNS 服务器上面去，可以看到此时已经是向 1.1.1.1 这个 IP 去获取 JS 了，而存放恶意 JS 的 IP 是 2.2.2.2，所以此时 XSS 失效。另外，1.1.1.1 是的一台可控制的 Nginx 服务器，配置文件做一个
- error_page 404 =200 /xss.js;
的配置可以保证每次都能取到 JS，获得 XSS 反馈。具体的代码实现在 Github 上。
实现起来比较简单，而且挺有意思，然而这样的防护方式实际比较简陋，所以说是一次尝试。
不足之处：
1、XSS Platform 通过 IP 访问;
2、XSS Platform 域名没有暴露;
3、防护的区域有限;
现在比较有效的几种方法：
1、重要站点开启 HTTPS，搭建过 XSS Platform 的话可以发现，改成 HTTPS 兼容需要注意很多小问题，所以现在很多平台图方便，都没有 HTTPS 的 JS 钩子。
2、CSP，本文的思路和实践，其实 CSP 都能优雅的实现，Block 或者 Report，但是相对网络复杂的企业来说推进起来比较复杂。
