[[172577]]

安全客點(diǎn)評

思路挺新穎的，雖然這種防護(hù)有一定的局限性，比如攻擊者用IP替代域名就繞過了，但是可以通過文中提及的XSS DNS防護(hù)方式了解到企業(yè)業(yè)務(wù)中有哪些WEB服務(wù)的XSS點(diǎn)正在被利用，方便排查，而且該防護(hù)措施部署上也不是很復(fù)雜。

前言

對于一個大的企業(yè)來說，要完全杜絕某一類型的漏洞是很難的，特別是 XSS 這種乍一看危害不大但是實(shí)際上影響面比較廣，而且觸發(fā)點(diǎn)相對來說比較多的漏洞。相關(guān)案例烏云上很多，有興趣的可以找烏云鏡像站看看。XSS 的利用在 XSS Platform 出現(xiàn)之后就變得簡單了，給頁面掛上一個 JS，然后剩下的全都交給 XSS Platform 去做，結(jié)果也從那里獲取，so easy，流程圖如下。

而很多人為了圖方便，并沒有自己搭建私有 XSS Platform，且不說這里存在漏洞泄漏的可能，免費(fèi)公共的 XSS Platform 往往就那么幾個，域名一般也不會變動，這里給了一種防護(hù)的思路。

XSS DNS 防護(hù)

如標(biāo)題所說，XSS DNS 防護(hù)，是因?yàn)樵谄髽I(yè)網(wǎng)絡(luò)中發(fā)起的 DNS 查詢是可以由企業(yè)自己的 DNS 服務(wù)器自由控制的，所以對于這種暴露的 XSS Platform 只要收集一下把這些域名都 block 掉就行了，這樣，企業(yè)網(wǎng)絡(luò)的 XSS 就少一些了。但是 XSS 并沒有自己消失只是無法觸發(fā)了而已，這時稍做修改就能把測試者的 XSS “偷” 過來，還是上面那個圖。

因?yàn)?DNS 是遞歸查詢的，所以如果企業(yè)網(wǎng)絡(luò)的 DNS 存在 evil.com 的記錄，那么這一條 DNS Query 就永遠(yuǎn)不會遞歸到 evil.com 域名 NS 記錄的 DNS 服務(wù)器上面去，可以看到此時已經(jīng)是向 1.1.1.1 這個 IP 去獲取 JS 了，而存放惡意 JS 的 IP 是 2.2.2.2，所以此時 XSS 失效。另外，1.1.1.1 是的一臺可控制的 Nginx 服務(wù)器，配置文件做一個

error_page 404 =200 /xss.js; 

的配置可以保證每次都能取到 JS，獲得 XSS 反饋。具體的代碼實(shí)現(xiàn)在 Github 上。

實(shí)現(xiàn)起來比較簡單，而且挺有意思，然而這樣的防護(hù)方式實(shí)際比較簡陋，所以說是一次嘗試。

不足之處：

1、XSS Platform 通過 IP 訪問;

2、XSS Platform 域名沒有暴露;

3、防護(hù)的區(qū)域有限;

現(xiàn)在比較有效的幾種方法：

1、重要站點(diǎn)開啟 HTTPS，搭建過 XSS Platform 的話可以發(fā)現(xiàn)，改成 HTTPS 兼容需要注意很多小問題，所以現(xiàn)在很多平臺圖方便，都沒有 HTTPS 的 JS 鉤子。

2、CSP，本文的思路和實(shí)踐，其實(shí) CSP 都能優(yōu)雅的實(shí)現(xiàn)，Block 或者 Report，但是相對網(wǎng)絡(luò)復(fù)雜的企業(yè)來說推進(jìn)起來比較復(fù)雜。