av激情亚洲男人的天堂国语,日韩欧美精品一中文字幕,无码av一区二区三区无码,国产又色又爽又刺激的a片,国产又色又爽又刺激的a片

前端安全保障之如何防止XSS攻擊？

 前端安全

隨著互聯(lián)網(wǎng)的高速發(fā)展，信息安全問題已經(jīng)成為企業(yè)最為關(guān)注的焦點(diǎn)之一，而前端又是引發(fā)企業(yè)安全問題的高危據(jù)點(diǎn)。在移動(dòng)互聯(lián)網(wǎng)時(shí)代，前端人員除了傳統(tǒng)的 XSS、CSRF 等安全問題之外，又時(shí)常遭遇網(wǎng)絡(luò)劫持、非法調(diào)用 Hybrid API 等新型安全問題。當(dāng)然，瀏覽器自身也在不斷在進(jìn)化和發(fā)展，不斷引入 CSP、Same-Site Cookies 等新技術(shù)來增強(qiáng)安全性，但是仍存在很多潛在的威脅，這需要前端技術(shù)人員不斷進(jìn)行“查漏補(bǔ)缺”。

近幾年，美團(tuán)業(yè)務(wù)高速發(fā)展，前端隨之面臨很多安全挑戰(zhàn)，因此積累了大量的實(shí)踐經(jīng)驗(yàn)。我們梳理了常見的前端安全問題以及對應(yīng)的解決方案，將會(huì)做成一個(gè)系列，希望可以幫助前端人員在日常開發(fā)中不斷預(yù)防和修復(fù)安全漏洞。本文是該系列的第一篇。

本文我們會(huì)講解 XSS ，主要包括：

  1.  XSS 攻擊的介紹
  2.  XSS 攻擊的分類
  3.  XSS 攻擊的預(yù)防和檢測
  4.  XSS 攻擊的總結(jié)
  5.  XSS 攻擊案例

XSS 攻擊的介紹

在開始本文之前，我們先提出一個(gè)問題，請判斷以下兩個(gè)說法是否正確：

  1.  XSS 防范是后端 RD（研發(fā)人員）的責(zé)任，后端 RD 應(yīng)該在所有用戶提交數(shù)據(jù)的接口，對敏感字符進(jìn)行轉(zhuǎn)義，才能進(jìn)行下一步操作。
  2.  所有要插入到頁面上的數(shù)據(jù)，都要通過一個(gè)敏感字符過濾函數(shù)的轉(zhuǎn)義，過濾掉通用的敏感字符后，就可以插入到頁面中。

如果你還不能確定答案，那么可以帶著這些問題向下看，我們將逐步拆解問題。

XSS 漏洞的發(fā)生和修復(fù)

XSS 攻擊是頁面被注入了惡意的代碼，為了更形象的介紹，我們用發(fā)生在小明同學(xué)身邊的事例來進(jìn)行說明。

一個(gè)案例

某天，公司需要一個(gè)搜索頁面，根據(jù) URL 參數(shù)決定關(guān)鍵詞的內(nèi)容。小明很快把頁面寫好并且上線。代碼如下：

 
 
 
      
  
  
  1. ">  
    2.   
  
  
  2.   
    3.   
  
  
  3.   
    4.   
  
  
  4.   您搜索的關(guān)鍵詞是：<%= getParameter("keyword") %>  
    5.
 

然而，在上線后不久，小明就接到了安全組發(fā)來的一個(gè)神秘鏈接：

http://xxx/search?keyword=">

小明帶著一種不祥的預(yù)感點(diǎn)開了這個(gè)鏈接[請勿模仿，確認(rèn)安全的鏈接才能點(diǎn)開]。果然，頁面中彈出了寫著"XSS"的對話框。

可惡，中招了！小明眉頭一皺，發(fā)現(xiàn)了其中的奧秘：

當(dāng)瀏覽器請求 http://xxx/search?keyword="> 時(shí)，服務(wù)端會(huì)解析出請求參數(shù) keyword，得到 ">，拼接到 HTML 中返回給瀏覽器。形成了如下的 HTML：

 
 
 
      
  
  
  1. ">  
    2.   
  
  
  2.   
    3.   
  
  
  3.   
    4.   
  
  
  4.   您搜索的關(guān)鍵詞是：">  
    5.
 

瀏覽器無法分辨出 是惡意代碼，因而將其執(zhí)行。

這里不僅僅 div 的內(nèi)容被注入了，而且 input 的 value 屬性也被注入， alert 會(huì)彈出兩次。

面對這種情況，我們應(yīng)該如何進(jìn)行防范呢？

其實(shí)，這只是瀏覽器把用戶的輸入當(dāng)成了腳本進(jìn)行了執(zhí)行。那么只要告訴瀏覽器這段內(nèi)容是文本就可以了。

聰明的小明很快找到解決方法，把這個(gè)漏洞修復(fù)：

 
 
 
      
  
  
  1. ">  
    2.   
  
  
  2.   
    3.   
  
  
  3.   
    4.   
  
  
  4.   您搜索的關(guān)鍵詞是：<%= escapeHTML(getParameter("keyword")) %>  
    5.
 

escapeHTML() 按照如下規(guī)則進(jìn)行轉(zhuǎn)義：

字符轉(zhuǎn)義后的字符
&&
<<
>>
""
''
//

經(jīng)過了轉(zhuǎn)義函數(shù)的處理后，最終瀏覽器接收到的響應(yīng)為：

 
 
 
      
  
  
  1.   
    2.   
  
  
  2.   
    3.   
  
  
  3.   
    4.   
  
  
  4.   您搜索的關(guān)鍵詞是："><script>alert('XSS');</script>  
    5.
 

惡意代碼都被轉(zhuǎn)義，不再被瀏覽器執(zhí)行，而且搜索詞能夠完美的在頁面顯示出來。

通過這個(gè)事件，小明學(xué)習(xí)到了如下知識：

注意特殊的 HTML 屬性、JavaScript API

自從上次事件之后，小明會(huì)小心的把插入到頁面中的數(shù)據(jù)進(jìn)行轉(zhuǎn)義。而且他還發(fā)現(xiàn)了大部分模板都帶有的轉(zhuǎn)義配置，讓所有插入到頁面中的數(shù)據(jù)都默認(rèn)進(jìn)行轉(zhuǎn)義。這樣就不怕不小心漏掉未轉(zhuǎn)義的變量啦，于是小明的工作又漸漸變得輕松起來。

但是，作為導(dǎo)演的我，不可能讓小明這么簡單、開心地改 Bug 。

不久，小明又收到安全組的神秘鏈接：http://xxx/?redirect_to=javascript:alert('XSS')。小明不敢大意，趕忙點(diǎn)開頁面。然而，頁面并沒有自動(dòng)彈出萬惡的“XSS”。

小明打開對應(yīng)頁面的源碼，發(fā)現(xiàn)有以下內(nèi)容：

 
 
 
      
  
  
  1. ">跳轉(zhuǎn)... 
    2.

這段代碼，當(dāng)攻擊 URL 為 http://xxx/?redirect_to=javascript:alert('XSS')，服務(wù)端響應(yīng)就成了：

 
 
 
      
  
  
  1. 跳轉(zhuǎn)... 
    2.

雖然代碼不會(huì)立即執(zhí)行，但一旦用戶點(diǎn)擊 a 標(biāo)簽時(shí)，瀏覽器會(huì)就會(huì)彈出“XSS”。

可惡，又失策了...

在這里，用戶的數(shù)據(jù)并沒有在位置上突破我們的限制，仍然是正確的 href 屬性。但其內(nèi)容并不是我們所預(yù)期的類型。

原來不僅僅是特殊字符，連 javascript: 這樣的字符串如果出現(xiàn)在特定的位置也會(huì)引發(fā) XSS 攻擊。

小明眉頭一皺，想到了解決辦法：

 
 
 
      
  
  
  1. // 禁止 URL 以 "javascript:" 開頭  
    2.   
  
  
  2. xss = getParameter("redirect_to").startsWith('javascript:');  
    3.   
  
  
  3. if (!xss) {  
    4.   
  
  
  4.   ">  
    5.   
  
  
  5.     跳轉(zhuǎn)...  
    6.   
  
  
  6.     
    7.   
  
  
  7. } else {  
    8.   
  
  
  8.     
    9.   
  
  
  9.     跳轉(zhuǎn)...  
    10.   
  
  
  10.     
    11.   
  
  
  11. } 
    12.

只要 URL 的開頭不是 javascript:，就安全了吧？

安全組隨手又扔了一個(gè)連接：http://xxx/?redirect_to=jAvascRipt:alert('XSS')

這也能執(zhí)行？.....好吧，瀏覽器就是這么強(qiáng)大。

小明欲哭無淚，在判斷 URL 開頭是否為 javascript: 時(shí)，先把用戶輸入轉(zhuǎn)成了小寫，然后再進(jìn)行比對。

不過，所謂“道高一尺，魔高一丈”。面對小明的防護(hù)策略，安全組就構(gòu)造了這樣一個(gè)連接：

http://xxx/?redirect_to=%20javascript:alert('XSS')

%20javascript:alert('XSS') 經(jīng)過 URL 解析后變成 javascript:alert('XSS')，這個(gè)字符串以空格開頭。這樣攻擊者可以繞過后端的關(guān)鍵詞規(guī)則，又成功的完成了注入。

最終，小明選擇了白名單的方法，徹底解決了這個(gè)漏洞：

 
 
 
      
  
  
  1. // 根據(jù)項(xiàng)目情況進(jìn)行過濾，禁止掉 "javascript:" 鏈接、非法 scheme 等  
    2.   
  
  
  2. allowSchemes = ["http", "https"];  
    3.   
  
  
  3. valid = isValid(getParameter("redirect_to"), allowSchemes);  
    4.   
  
  
  4. if (valid) {  
    5.   
  
  
  5.   ">  
    6.   
  
  
  6.     跳轉(zhuǎn)...  
    7.   
  
  
  7.     
    8.   
  
  
  8. } else {  
    9.   
  
  
  9.     
    10.   
  
  
  10.     跳轉(zhuǎn)...  
    11.   
  
  
  11.     
    12.   
  
  
  12. } 
    13.

通過這個(gè)事件，小明學(xué)習(xí)到了如下知識：

根據(jù)上下文采用不同的轉(zhuǎn)義規(guī)則

某天，小明為了加快網(wǎng)頁的加載速度，把一個(gè)數(shù)據(jù)通過 JSON 的方式內(nèi)聯(lián)到 HTML 中：

 
 
 
      
  
  
  1.  
    2.

插入 JSON 的地方不能使用 escapeHTML()，因?yàn)檗D(zhuǎn)義 " 后，JSON 格式會(huì)被破壞。

但安全組又發(fā)現(xiàn)有漏洞，原來這樣內(nèi)聯(lián) JSON 也是不安全的：

掃二維碼與項(xiàng)目經(jīng)理溝通

我們在微信上24小時(shí)期待你的聲音

解答本文疑問/技術(shù)咨詢/運(yùn)營咨詢/技術(shù)建議/互聯(lián)網(wǎng)交流

其他資訊