【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提供了四種字符編碼的策略：

　　　  一、三個八進制數字，若是不夠個數，前面補0，例如「e」編碼爲「\145」 　　　　

　　　　二、兩個十六進制數字，若是不夠個數，前面補0，例如「e」編碼爲「\x65」 　　　　

　　　　三、四個十六進制數字，若是不夠個數，前面補0，例如「e」編碼爲「\u0065」 　　　　

　　　　四、對於一些控制字符，使用特殊的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^)/~