提起防御網(wǎng)絡(luò)攻擊，很多同學(xué)只知道需要轉(zhuǎn)義，編碼。但是這個(gè)話題實(shí)際上博大精深，不止這四個(gè)字這么簡(jiǎn)單。
文章目錄：
- 常見(jiàn)的 XSS 攻擊類(lèi)型
- 不止如此
- 談?wù)劮烙?/li>
- 總結(jié)
常見(jiàn)的 XSS 攻擊類(lèi)型
某天前端打雜小劉和后端同學(xué)在給現(xiàn)有業(yè)務(wù)加搜索功能，前端同學(xué)在展示模糊搜索結(jié)果的同時(shí)，需要展示用戶當(dāng)前搜索的字段，比如『沒(méi)有關(guān)于 *** 的搜索內(nèi)容』。在沒(méi)有任何防御措施的時(shí)候，用戶輸入<script>alert(1)</script>，就有可能直接彈出在頁(yè)面上。這就是反射型 XSS 攻擊。還是這個(gè)搜索功能，如果有一天產(chǎn)品心血來(lái)潮要加一個(gè)『朋友們的最近搜索』功能，依然是在沒(méi)有任何防御的時(shí)候，某個(gè)用戶還是搜索<script>alert(1)</script>，那么其他用戶訪問(wèn)時(shí)就有可能彈框，這就是存儲(chǔ)型（持久型）XSS 攻擊。
從上面這個(gè)例子可以看出，所謂反射型，是發(fā)生在當(dāng)前用戶的某些請(qǐng)求或者頁(yè)面訪問(wèn)的 url 中攜帶的某些字段，回顯到頁(yè)面或者影響到當(dāng)前頁(yè)面的一些執(zhí)行過(guò)程。但是并沒(méi)有存儲(chǔ)到數(shù)據(jù)庫(kù)中，意味著不會(huì)影響到其他訪問(wèn)這個(gè)頁(yè)面的用戶。
存儲(chǔ)型則不同，像剛才的例子，我們把用戶最近輸入的內(nèi)容存儲(chǔ)到數(shù)據(jù)庫(kù)，以在他的關(guān)聯(lián)用戶訪問(wèn)時(shí)可以展示。這種攻擊會(huì)影響到其他的用戶。
DOM-based XSS 又是什么？很多文章指出DOM-based是反射型 XSS 的一種，但是我個(gè)人認(rèn)為不太對(duì)，下面附上 mediawiki 的解釋?zhuān)?/p>
DOM-based XSS (or type-0 XSS) is a type of Cross-site scripting attack that occurs when client-side scripts (such as JavaScript) manipulate the page's DOM, allowing an attacker to run JavaScript in the victim's browser.
This class of XSS is distinct from Reflective XSS (type-1 XSS) and Stored XSS (type-2 XSS), since the server is not returning executable JavaScript to the browser. Instead, data that has been sanitized by the server, or possibly never sent to the server, is converted to executable JavaScript by the existing code running on the page.
只要是在客戶端腳本操作頁(yè)面 DOM 時(shí)運(yùn)行了攻擊者的 javascript 腳本，都?xì)w類(lèi)于 DOM-based XSS。也就是說(shuō)他概括的維度更貼近于觸發(fā)的出口，而不是方式。所以他其實(shí)和反射型，存儲(chǔ)型是有交叉的。DOM-based XSS 甚至不依賴于請(qǐng)求，只在客戶端本身就具備發(fā)生此類(lèi)攻擊的條件。
不止如此
繼續(xù)回到前端打雜小劉的故事。測(cè)試同學(xué)在安全測(cè)試的過(guò)程中，反饋了 bug。前端同學(xué)和后端同學(xué)兩個(gè)人開(kāi)始商量怎么處理。轉(zhuǎn)義！兩人一拍即合。后端同學(xué)針對(duì)字符串類(lèi)型的數(shù)據(jù)進(jìn)行實(shí)體化轉(zhuǎn)義
[圖片上傳失敗...(image-16800d-1524309858885)]
小劉在自己調(diào)用 innerHTML 方法的參數(shù)前也加了一層轉(zhuǎn)義。大功告成！
沒(méi)高興幾個(gè)小時(shí)，測(cè)試又提過(guò)來(lái)一個(gè) bug 。小劉當(dāng)時(shí)偷懶，直接在標(biāo)簽上寫(xiě)了dom 0級(jí)事件。如下寫(xiě)法：
<button onclick=`alert(${name})`></button>
而 name 是依賴于用戶輸入的。如果用戶輸入的 name 為：);alert(document.cookie 你看會(huì)發(fā)生什么？小劉驚訝于還有這種操作的同時(shí)，也深刻意識(shí)到了防范 XSS 攻擊遠(yuǎn)遠(yuǎn)不止簡(jiǎn)單實(shí)體化轉(zhuǎn)義 HTML 代碼這么簡(jiǎn)單。我們需要對(duì)不同的應(yīng)用場(chǎng)景，和你的代碼，來(lái)做不同的轉(zhuǎn)義。在這個(gè)例子里，我們需要對(duì)拼接進(jìn)事件中的用戶字符串進(jìn)行一次 javascript 編碼（這里科普一下 javascript 編碼指的就是 unicode 編碼）即：
<h1 class="title" onclick="alert('\u0027\u0029\u003b\u0061\u006c\u0065\u0072\u0074\u0028\u0027\u0053\u0052\u0043')">點(diǎn)擊彈出</h1>
類(lèi)似的場(chǎng)景還有很多，最近還有針對(duì) css 攻擊防御的文章，大家有時(shí)間可以了解一下。但是萬(wàn)變不離其宗，我們要秉持懷疑所有用戶輸入的態(tài)度，有針對(duì)性的轉(zhuǎn)義和編碼，而不是只是知道需要轉(zhuǎn)義這么簡(jiǎn)單。
談?wù)劮烙?/h4>
在上面一個(gè)小節(jié)已經(jīng)講過(guò)轉(zhuǎn)義的基本用法和針對(duì)的場(chǎng)景。下面來(lái)說(shuō)一些老生常談的話題：哪些是前端不能做的雷區(qū)。
new function、echo、innerHTML、dom 0 級(jí)事件等等。尤其是當(dāng)他們的內(nèi)容和用戶輸入有關(guān)聯(lián)的時(shí)候，都有可能形成漏洞。
總結(jié)
- XSS 防范是需要我們?cè)陴B(yǎng)成好的寫(xiě)碼習(xí)慣的同時(shí)，還要對(duì)所有用戶輸入保持警惕。
- 不能把自己的安全建立在其他接口是否返回正確的基礎(chǔ)上，所以最好在前端也要加一層校驗(yàn)，而不能完全依賴后端。
- 現(xiàn)代瀏覽器很多都對(duì)類(lèi)似的情況有過(guò)濾和處理，但是并不完備。大多數(shù)的模板引擎和框架內(nèi)部也多有針對(duì) XSS 的防范。
推薦閱讀：
淺談XSS—字符編碼和瀏覽器解析原理
如何讓前端更安全？——XSS 攻擊和防御詳解
DOM-based XSS 與存儲(chǔ)性 XSS、反射型 XSS 有什么區(qū)別？
