天天看點

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

SRC漏洞挖掘之存儲型XSS

  • 0x01 漏洞簡介
  • 0x02 漏洞分析
    • 01 敏銳的嗅覺很重要
    • 02 漫長的繞過過程
    • 03 偶然發現,挖洞也需要一點運氣
  • 0x03 修複建議
  • 0x04 參考連結

0x01 漏洞簡介

某天閑來無聊,打開我的burp、火狐、chrome浏覽器,随便找了一個目标,便開始了漏洞挖掘之旅。

故事要從一個評論開始說起,打開網站的論壇,一個顯眼的标題映入眼簾,“真人MM主播全天線上直播表演”,咳咳。。。,開玩笑的啦,哦也是個正經銀啦。就是正常的文章,也是一時興起,随手留個個言,抓了個包,然後便有了這篇文章。本篇有意思的點在于網站本身是有過濾的,下面我會講解我當時的繞過思路,大佬勿噴。

0x02 漏洞分析

01 敏銳的嗅覺很重要

剛剛說到留言抓包,資料包截圖如下

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

碼打的有點多,見諒哈。一般我們挖洞,第一個就是觀察力,看到以下資料包大家發現了什麼呢。是不是看到了很顯眼的%3Cp%3E,一般看到這種資料包的時候,我們就要留意了,這裡是很可能存在xss漏洞的,因為如果标簽過濾不嚴格,是會導緻直接寫入惡意xss标簽的。但是這種低級錯誤,在這裡是不會有的,畢竟也是被搞得多了,多少也有點安全經驗,不過也隻是有點而已。

02 漫長的繞過過程

既然資料包中存在html标簽,那我們就從标簽測起。首先,肯定是第一個嘗試老大哥

果不其然,被過濾了,從過濾規則來看,應該是使用的黑名單+正則的過濾方式,當比對到script标簽的時候,自動在左右兩邊添加xss字元串,這樣xss語句就無法執行了。

過濾了script,沒事,我們還有很多标簽沒有嘗試呢。這裡推薦一個大佬寫的XSS過濾繞過速查表,附在參考連結了。後面嘗試了<img/src=1>,伺服器提示src隻能為站内連結(沒有截圖),然後我又把src屬性去掉,嘗試寫入,送出後發現直接被删掉了。好吧,看來img标簽暫時是用不了了。

後面又陸陸續續嘗試了以下标簽,object、div、iframe、a、meta、style、svg等等一些列标簽,基本都陣亡了,直接被删除了,唯一存活下來的标簽input、select,如圖

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

好吧,既然還有存活的标簽,那麼我們就不能放棄,繼續盤起!嘗試完html标簽,我們現在就要嘗試html事件處理程式,先是最常用的onmouseover,送出後如圖

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

可以看到,onmouseover中的on直接被替換了為了xss_,說明我們之前的猜測是正确的,後端就是使用的正則+黑名單的方式進行過濾的,javascript、eval、alert也是一樣被過濾的。後面也經過一系列的嘗試,發現都會被替換掉,這個時候也是有點陷入僵局了。要說不是xss注入點,它又能寫入少數html标簽,但你說是xss注入點嘛,能用的标簽和事件都給你堵死了,有點食之無味,棄之可惜的感覺。但是本着白帽子的勇往直前,義無反顧,大義滅親,所向無敵,,,扯遠了,反正就是那種精神吧,咱們也不能放棄這個漏洞,是不。

03 偶然發現,挖洞也需要一點運氣

就在丢棄,又有點可惜的心理下,我又進行了一些嘗試,主要是标簽上的嘗試,因為是采用的黑名單過濾,如果有能逃過去的标簽,并且能夠寫入可執行腳本,那麼還是有希望的。

也是運氣吧,不能說是全靠實力,在不斷的嘗試中,無意間有了意外發現。當我們寫入标簽的時候,我發現傳回内容為< a>,這個時候敏銳的嗅覺告訴我,有戲了!

可以從傳回中發現,details被剔除了,但是後面的空格和a都被完整保留下來了,學過sql注入繞過的童鞋應該都能想到,在黑名單過濾中,如果能找到一個會被替換為空的字元,那麼就可以利用該字元來構造sql語句,進而繞過黑名單校驗。

這裡也是同樣的原理,既然直接送出會被檢測到,那麼我們就來變下形 ,送出後服務端傳回如圖

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

可以看到成功寫入資料庫了,再來重新整理看一下前端頁面,如圖

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

檢視後發現,script多了一個點,果然沒那麼簡單啊,呵呵。後面嘗試通過事件來觸發,如圖

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

其實服務端是成功寫入了,但是考慮是輸出時也做了過濾或者前端腳本做了過濾,總之payload随你寫入,就是不讓你成功執行,哎,就是玩!

但是,都已經到了這一步,哪能輕易放棄,必須一戰到底啊。

發現事件還是無法使用之後,我又開始了新的嘗試,既然你非要在script後面加個點,那我就把你注釋掉,實際測試中是可以注釋的,測試代碼如下

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結
SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

可以看到,這樣子是可以執行的,但是!但是!我們能想到的,可愛的開發童鞋也想到了,/直接被前端過濾了,寫入資料庫是可以的,如圖

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

看一下前端的效果,如圖

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

嘗試寫入兩個反斜線,如圖(<script/ /></script/ />)

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

可以看到中間多了個空格,看下前端的情況,如圖

SRC漏洞挖掘之存儲型XSS0x01 漏洞簡介0x02 漏洞分析0x03 修複建議0x04 參考連結

嗯哼,熟悉的感覺瞬間就出來了,看來開發隻考慮了一個斜線的情況,當存在兩個斜線時,第二個被隔開,但是第一個沒有與script隔開,傳送到前端的時候,由于無法識别 script/ 是以隻去除了斜線,而沒有添加一點,最終導緻我們成功繞過。

後面就不用說了,能寫入script标簽了,啥都有了。

當我們遇到可以寫入少數html标簽,但是又存在過濾的時候,千萬不要放棄,多加fuzz嘗試,你終将會找到打開那把鎖的鑰匙!

0x03 修複建議

  1. 嚴格過濾使用者輸入的資料
  2. 使用白名單過濾校驗

0x04 參考連結

XSS過濾繞過速查表

繼續閱讀