XSS跨站腳本攻擊

1、簡介

XSS（cross site script）是指惡意攻擊者利用網站沒有對用戶提交數據進行轉義處理或者過濾不足的缺點，進而添加一些代碼，嵌入到web頁面中去。使別的用戶訪問都會執行相應的嵌入代碼，從而盜取用戶資料、利用用戶身份進行某種動做或者對訪問者進行病毒侵害的一種攻擊方式。

XSS是一種常常出如今web應用中的計算機安全漏洞，也是web中最主流的攻擊方式。

2、緣由解析

主要緣由：過於信任客戶端提交的數據，客戶端提交的數據原本就是應用所須要的，可是惡意攻擊者利用網站對客戶端提交數據的信任，在數據中插入一些符號以及javascript代碼，那麼這些數據將會成爲應用代碼中的一部分了。那麼攻擊者就能夠肆無忌憚地展開攻擊啦。

解決辦法：不信任任何客戶端提交的數據，只要是客戶端提交的數據就應該先進行相應的過濾處理而後方可進行下一步的操做。

3、XSS攻擊分類

一、反射型XSS

又稱爲非持久性跨站點腳本攻擊，它是最多見的類型的XSS。漏洞產生的緣由是攻擊者注入的數據反映在響應中。一個典型的非持久性XSS包含一個帶XSS攻擊向量的連接(即每次攻擊須要用戶的點擊)。

二、存儲型XSS

又稱爲持久型跨站點腳本，它通常發生在XSS攻擊向量(通常指XSS攻擊代碼)存儲在網站數據庫，當一個頁面被用戶打開的時候執行。每當用戶打開瀏覽器,腳本執行。持久的XSS相比非持久性XSS攻擊危害性更大,由於每當用戶打開頁面，查看內容時腳本將自動執行。

三、DOM Based XSS

當用戶可以經過交互修改瀏覽器頁面中的DOM並顯示在瀏覽器上時，就有可能產生這種漏洞，從效果上來講它也是反射型XSS。經過修改頁面的DOM節點造成的XSS，稱之爲DOMBasedXSS。

容易致使DOM型的XSS的輸入源包括：
Document.URL
Document.referrer
Document.cookie
Window.name
Location.[pathname|href|search|hash]
localStorage/globalStorage

3、XSS攻擊

1. 繞過XSS-Filter，利用 <> 標籤注入 HTML/JavaScript 代碼；
2. 利用HTML標籤的屬性值進行XSS攻擊。例如：<img src=「javascript:alert(‘xss’)」/>；（固然並非全部的Web瀏覽器都支持Javascript僞協議，因此此類 XSS 攻擊具備必定的侷限性）
3. 空格、回車和Tab。若是XSS Filter僅僅將敏感的輸入字符列入黑名單，好比javascript，用戶能夠利用空格、回車和Tab鍵來繞過過濾，例如：<img src=「javas cript:alert(/xss/);」/>；
4. 利用事件來執行跨站腳本。例如：<img src=「#」 onerror= 「alert(1)」/>，當src錯誤，就會執行onerror事件；
5. 利用CSS跨站。例如：body {backgrund-image: url(「javascript:alert(‘xss’)」)}；
6. 擾亂過濾規則。例如：<IMG SRC=「javaSCript: alert(/xss/);」/>；
7. 利用字符編碼，經過這種技巧，不只能讓XSS代碼繞過服務端的過濾，還能更好地隱藏Shellcode；（JS支持unicode、eacapes、十六進制、十進制等編碼形式）；
8. 拆分跨站法，將XSS攻擊的代碼拆分開來，適用於應用程序沒有過濾XSS關鍵字符（如<、>）卻對輸入字符長度有限制的狀況下；
9. DOM型XSS主要是由客戶端的腳本經過DOM動態地輸出數據到頁面上，它不依賴於提交數據到服務器，而是從客戶端得到DOM中的數據在本地執行。

4、XSS防護措施

一、使用 XSS Filter

針對用戶提交的數據進行有效的驗證，只接受咱們規定的長度或內容的提交，過濾掉其餘的輸入內容。好比：

• 表單數據指定值的類型：年齡只能是 int 、name 只能是字母數字等。
• 過濾或移除特殊的 html 標籤：<script>、<iframe>等。
• 過濾 js 事件的標籤：onclick、onerror、onfocus等。

二、HTML編碼

對用戶輸入的數據進行HTML Entity編碼 。

字符	十進制	轉義字符
"	"	"
&	&	&
<	&#60;	&lt;
>	&#62;	&gt;
空格	&#160;	&nbsp;

三、JavaScript編碼

使用「」對特殊字符進行轉義，除數字字母以外，小於127使用16進制「xHH」的方式進行編碼，大於用unicode.

這條原則主要針對動態生成的JavaScript代碼，這包括腳本部分以及HTML標籤的事件處理屬性（如onerror, onload等）。在往JavaScript代碼裏插入數據的時候，只有一種狀況是安全的，那就是對不可信數據進行JavaScript編碼，而且只把這些數據放到使用引號包圍起來的值部分（data value）之中。

注意：在對不可信數據作編碼的時候，不能圖方便使用反斜槓 對特殊字符進行簡單轉義，好比將雙引號 " 轉義成 " ，這樣作是不可靠的，由於瀏覽器在對頁面作解析的時候，會先進行HTML解析，而後纔是JavaScript解析，因此雙引號極可能會被當作HTML字符進行HTML解析，這時雙引號就能夠突破代碼的值部分，使得攻擊者能夠繼續進行XSS攻擊；另外，輸出的變量的時候，變量值必須在引號內部，避免安全問題；更加嚴格的方式，對除了數字和字母之外的全部字符，使用十六進制xhh 的方式進行編碼。

四、其餘

1. 將重要的cookie標記爲http only, 這樣的話Javascript 中的document.cookie語句就不能獲取到cookie了.
2. 對數據進行Encode 處理
3. CSP: Content-Security-Policy(內容安全策略)

   <meta http-equiv="Content-Security-Policy" content="xxxxxxxxxx">

五、代碼

/**
 * 使用：引入: import base from '../../../../vv-base/vue/base.js'
         調用: base.toUrl('http://www.baidu.com')
 */
const base={
     /**
     * 內容轉義
     * eg: 使用v-html時,進行轉義
     */
     toHtml(val) {
        var entityMap = {
            "&": "&",
            "<": "&lt;",
            ">": "&gt;",
            '"': '&quot;',
            "'": '&#39;',
            "/": '&#x2F;'
        };
        return String(val).replace(/[&<>"'\/]/g, function (s) {
            return entityMap[s];
        });
    },
    /**
     * a標籤中的href屬性值轉義
     * eg: <a :href="base.toUrl(url)"></a>
     */
    toUrl(url) {
        if(url.match(/^http/i)){
            return encodeURI(url)
        }
        return '#'
    }
}
export default base;

5、參考

根據白名單過濾 HTML(防止 XSS 攻擊)
XSS Filter Evasion Cheat Sheet 中文版
https://segmentfault.com/a/11...