存儲型xss調研

 

 

概念

存儲型XSS，持久化，代碼是存儲在服務器中的，如在我的信息或發表文章等地方，加入代碼，若是沒有過濾或過濾不嚴，那麼這些代碼將儲存到服務器中，用戶訪問該頁面的時候觸發代碼執行。

 

常見的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中的數據在本地執行。容易致使DOM型的XSS的輸入源包括：Document.URL、Location(.pathname|.href|.search|.hash)、Document.referrer、Window.name、Document.cookie、localStorage/globalStorage；

 

 

傳統XSS防護手段

如何根治XSS呢,這裏能夠負責任的告訴你,沒有一種防護方法是通用萬能的。XSS攻擊方式根據漏洞出現位置、瀏覽器環境、業務環境、攻擊目的、WebServer類型的不一樣而變化(因此XSSer們每每稱本身爲猥瑣流)。它不像其餘web漏洞：上傳、SQL注入、文件包涵，僅僅須要在服務器上作下過濾（甚至是安裝一個統一過濾腳本或者WAF）就能夠成功防護的，因此根據實際狀況，針對XSS防護措施也是不一樣的，大致來講，有如下幾點:

 

1.服務器端過濾

服務器端轉義輸入的左右尖括號，對HTML標籤進行編碼，這是主流的防護XSS的方法，可有效防護通常的XSS攻擊。

 

2.前端過濾

把變量輸出到頁面時要作好相關的編碼轉義工做，如要輸出到 <script>中，能夠進行JS編碼；要輸出到HTML內容或屬性，則進行HTML編碼處理。

輸入過濾，對用戶提交的數據進行有效性驗證，僅接受指定長度範圍內並符合咱們指望格式的的內容提交，阻止或者忽略除此外的其餘任何數據。好比：電話號碼必須是數字和中劃線組成，並且要設定長度上限。過濾一些些常見的敏感字符，例如：< > ‘ 「 & # \ javascript expression  "onclick="  "onfocus"；過濾或移除特殊的Html標籤， 例如: <script>, <iframe> ,  < for <, > for >, " for；過濾JavaScript 事件的標籤，例如 "onclick=", "onfocus" 等等。

輸出編碼，當須要將一個字符串輸出到Web網頁時，同時又不肯定這個字符串中是否包括XSS特殊字符（如< > &‘」等），爲了確保輸出內容的完整性和正確性，可使用編碼（HTMLEncode）進行處理

 

3.HttpOnly

在服務器端作配置，在響應頭裏對cookie中的session進行httponly標記，被標記的session沒法被js讀出，所以能夠有效防護針對偷取cookie的XSS攻擊。

 

4.Content Security Policy (CSP)

CSP策略規範了網頁中某個標籤所能加載的第三方域，從協議層把一些存在安全隱患的用法默認給幹掉，把同源同域更發揮到了極致，結合禁止內聯腳本的機制，能夠有效防護大部分XSS攻擊。

缺點: 須要在服務器端進行配置，並且一旦配置不當，正常業務也會受到影響。配置不嚴格又會致使繞過。對於大型的、複雜的網站業務，維護成本較高。

 

5.XSS防火牆技術

這種技術目前正處於概念階段，並無大範圍投入使用，其思路是用js代碼來對當前網頁進行防禦，防止發生XSS行爲。並且設計理念也是各有不一樣。

像百度FEX設計的這款，模擬了CSP策略實現了對XSS的防護。

http://fex.baidu.com/blog/2014/06/xss-frontend-firewall-4/

 

 

過濾流程圖：

 

針對過濾流程中的標籤及黑屬性，這裏就很少說了，發現刪除就能夠，這裏重點說下屬性值安全，屬性值大致分爲3類

URL

這裏指的URL，就是相似href，src等的值，這裏核心的就是按照URL標準識別出引入的URL的協議，保留容許的協議便可，好比 

 

CSS

爲何要提到CSS呢，由於CSS是富文本UGC的一個核心，由於沒有CSS，QQ空間日誌內容則達不到用戶想要的炫酷效果，爲了保證CSS的安全，咱們又得再實現一個CSS語法解析器(因爲當時場景須要，咱們是本身寫的，不過你們也能夠參考CSS Parse的開源代碼)。

因爲CSS的強大，因此咱們首先定義了一串黑名單，好比出現expression，background，javascript，eval一旦出現這些黑名單，這裏以前犯過一個錯誤，就是採用刪除邏輯，當遇到下面的case，真的是欲哭無淚，後來評估正常UGC，極少出現黑名單裏的用法，so直接清空css。 

 

坑1：在完成黑名單清理後，你會發現IE瀏覽器居然兼容以下格式的CSS(強大的\) 

 

坑2：同時IE還兼容以下格式(&#編碼，尼瑪的支持編碼就算了，最後的;還無關緊要) 

 

坑3：你覺得他只認識html編碼嘛，其實你錯了，他還認識unicode編碼。 

 

沒辦法，通通黑名單搞之：出現\ 或 &# 通通清空CSS啊，清空CSS。

坑4：此時，你覺得CSS應該沒事了，可是IE又出現新的兼容方式：全角字符 

 

繼續搞，只要出現全角字符，一律清空。

Flash

講到Flash安全，就重點保障2個屬性值設置合理就好了：

allowScriptAccess： & allowNetworking

若是條件容許建議統一設置爲：allowScriptAccess設置爲never，allowNetworking設置爲none

可是業務每每須要這2個屬性，好比QQ空間日誌中要能播放QQ音樂，因此須要首先識別出引入的Flash地址，而後僅對白名單的放開該權限便可。

這裏強烈建議你們不要使用object，由於他比embed處理要麻煩N倍，同時IE大爺對它兼容也超好，好比當識別屬性名時，以下編碼格式也是容許的：