【web安全】第二彈：XSS攻防中的復合編碼問題

最近一直在研究XSS的攻防，特別是dom xss，問題慢慢的遷移到瀏覽器編碼解碼順序上去。

今兒被人放鴿子，無奈在KFC看了兩個小時的資料，突然有種豁然開朗的感覺。

參考資料先貼出來：

1. http://www.freebuf.com/articles/web/43285.html

2. http://www.freebuf.com/articles/web/10121.html

3. http://www.wooyun.org/whitehats/%E5%BF%83%E4%BC%A4%E7%9A%84%E7%98%A6%E5%AD%90

4. 道哥：白帽子講Web安全

5. 編碼轉換工具：http://app.baidu.com/app/enter?appid=280383

 

　　通常在XSS防御中，輸出在HTML標簽中或HTML屬性中的情況最為常見，瀏覽器也只會進行HTML解碼，只需要對輸出進行HTML編碼就可以解決XSS問題。但如果涉及輸出在腳本或者URL中的時候就要進行其他方式的編碼。本文的重點就是研究在復雜環境中輸出變量的編碼問題。

【基本知識----常見編碼及起因】

 HTML編碼

       在呈現HTML頁面時,有時候需要顯示一些特殊的字符,例如”<”和”&”,因為它們是HTML專用字符，需要通過一定的方式來實現，HTML編碼由此誕生。HTML編碼只是一種函數體現，用於將字符轉換成HTML實體。例如想要顯示<script>，在代碼中需要寫成“&lt;script&gt;“。為了防止XSS，至少要轉換以下字符：

字符	HTML實體
<	&lt;
>	&gt;
‘	&#039;
“	&quot;
&	&amp;

　　同時字符編碼也是實現HTML編碼的一種形式。十進制、十六進制ASCII碼或unicode字符編碼，樣式為“&#數值;”。例如想要顯示<script>，在代碼中可以寫成“&#x003c;script&#x003e;”或者“&#60;script&#62;”。

Javascript編碼

      JavascriptEncode可以采用跟HtmlEncode不同的編碼方式，即使用“\”對特殊字符進行轉義。也可以轉換成對應的字符編碼。js提供了四種字符編碼的策略：

　　　  1、三個八進制數字，如果不夠個數，前面補0，例如“e”編碼為“\145” 　　　　

　　　　2、兩個十六進制數字，如果不夠個數，前面補0，例如“e”編碼為“\x65” 　　　　

　　　　3、四個十六進制數字，如果不夠個數，前面補0，例如“e”編碼為“\u0065” 　　　　

　　　　4、對於一些控制字符，使用特殊的C類型的轉義風格（例如\n和\r）

URL編碼

      Url參數字符串中使用key=value鍵值對這樣的形式來傳參，鍵值對之間以&符號分隔，如/s?q=abc&ie=utf-8。如果你的value字符串中包含了=或者&，那么勢必會造成接收Url的服務器解析錯誤，因此必須將引起歧義的&和=符號進行轉義，也就是對其進行編碼。字符編碼方式為：%號后面加上字符的十六進制來替換這些有沖突的字符,例如將空格替換為%20。

【瀏覽器解析原理】

　　瀏覽器在接收到一個HTML文件時，會從頭開始對文檔進行解析。遇到javascript時，會調用javascript解析器進行解析。遇到類似Onclick等需要觸發才會執行的代碼會跳過，事件被觸發時才會被解析。

【實例一】

<a href="#" onclick="{$value}">天氣不錯</a>

瀏覽器解析時，onclick中的內容被當做HTML來解析。在點擊鏈接之后，調用javascript解析器來解析$value。

所以解碼的順序：HTML解碼->JavaScript解碼。

所以正確的防御對策為：JavaScript編碼->HTML編碼。

【實例二】

<div id="bb"></div>

<script>

　　document.getElementById('bb').innerHTML="{$value}";

</script>

瀏覽器解析時，$value位於JavaScript中，先被Javascript解碼。后$value被賦值到HTML中，進行HTML解碼。

所以解碼順序為：JavaScript解碼->HTML解碼

所以正確的防御對策為:HTML編碼->JavaScript編碼

【實例三】

<td onclick=”openUrl(add.do?userName=’{$value}’);”>11</td>

瀏覽器解析時，$value位於Javascript中，但由於是在onclick中，所以先以HTML的身份被解碼。被點擊之后，先被JavaScript解碼。由於$value還是URL的一部分，所以還會被URL解碼。

所以解碼順序為：HTML解碼->JavaScript解碼->URL解碼

所以正確的防御對策為：URL編碼->JavaScript編碼->HTML編碼

 

【寫在最后】

在編碼不合理的情況下的繞過方法在參考資料里寫的很清楚啦，這篇文章只是整理一下思路哈~

這幾天嘗試着去挖挖漏洞好啦~\(^o^)/~