[[172577]]

安全客點評

思路挺新穎的，雖然這種防護有一定的局限性，比如攻擊者用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，但是相對網絡復雜的企業來說推進起來比較復雜。