xss漏洞掃描器開發隨想

前言

很喜歡xss的各種腦洞打開的利用方式,也想着能夠實現自動挖掘xss,但是個人覺得像大多數漏洞掃描器那樣用收集的大量的payload,採用暴力測試的那種手段不夠聰明,後來也發現了一款宣稱smarter的xss掃描器——xssstrike,也去認真讀了下源代碼,發現確實是一款很聰明的漏掃,在學習了它的源碼過後,不動手自己也寫一個總覺得會遺憾,於是就有了下面的構思

思路

想一想我們平時是怎麼挖掘xss漏洞的?

  1. 查找輸入點
  2. 哪些輸入點會有輸出
  3. 輸入一些特殊字符以此判斷哪些字符被過濾
  4. 知道過濾規則過後開始考慮編寫能夠繞過過濾的payload
  5. 根據頁面是否彈窗等信息判斷是否存在xss

上面的流程應該算是一個比較粗略地挖掘流程吧,現在我們要做的就是把這個流程自動化,當然,計算機是很笨的,有些人可以一眼就識別出來的特徵機器需要我們告訴它一步步怎麼做,這也就是難點所在了。

確定輸入

掃描器的目的就是提高我們的挖掘效率,重複性的工作都可以丟給他做,如果手工測試每個參數是否存在xss漏洞,我們就需要多次重複上面的步驟,所以我們可以做一個掃描器一次只判斷一個參數或幾個參數是否存在xss(我們只需要提供url和指定需要測試的參數),或者做一個可以挖掘整個站點xss漏洞的掃描器(利用爬蟲爬取整個網站的表單以及url,依次測試)

指定參數這種測試方式倒是挺簡單的,整站測試稍微要複雜一點,需要做一個爬蟲爬取鏈接並進行數據清洗,去掉外鏈等

確定輸出

確定輸出也挺簡單的,就是利用requests庫,參數賦值爲特定的字符串,然後獲取到響應,並在響應中利用正則匹配那個字符串,如果匹配成功,那麼我們就找到輸出點了。

但是上面僅僅是確定哪些參數能夠輸出在頁面上,並沒有進一步確認輸出點到底在哪裏,例如輸出在標籤中?輸出在屬性中?這些也是一個聰明的掃描器需要得到的信息,畢竟後續生成payload需參考這些信息來實現定製化。好的,我們想一下手工測試的時候我們會怎麼做,根據經驗,我們通常把輸入分爲:

  1. 標籤之間
  2. 作爲html屬性值
  3. script標籤之間
  4. 註釋中

一般來說,如果輸出在標籤之間的話利用就不會那麼麻煩,但是需要注意輸出是否是在textarea noscript title noframes iframe xmp plaintext這些特殊標籤內,這些標籤會對輸出在它們之間的內容進行htmlencode。

作爲屬性值,需要判斷是哪些屬性,是不是on開頭的屬性(onclick,onfocus),是不是src,href等,這些屬性是有不同的利用方式的,如果排除掉上面幾種可能,就需要再判斷屬性值是否被引號(雙引號、單引號)包裹

在script標籤的話,情況是很複雜的,輸出可能作爲一個變量值,可能是函數的某個形參,可能是函數名,可能是局部變量。這種情況是很難確定是否有漏洞存在的…

如果輸出在html註釋中,我們需要做的就是逃逸註釋

waf探測

waf探測到底該放在什麼時候進行,讀者自己把控。在滲透測試中,waf是一個挺讓人頭痛的存在,惡意請求、http請求頻率過高都可能導致ip被ban掉,所以我們需要探測一下waf是否存在以此來決定下一步的動作。原理倒也很簡單,用一個惡意請求去觸發waf,然後進行特徵匹配

過濾檢查

即使沒有waf,稍微有點安全意識的開發人員都會對用戶輸入的特殊字符進行過濾,所以在進行payload構造之前,我們需要確定哪些字符我們可以使用,否則可能生成的payload大部分不能使用,豈不是很虧?而xsstrike中檢查過濾的原理是用我們需要檢測的特殊字符拼接上特定字符串,然後請求發過去,最後在響應中尋找拼接了特殊字符串的字符,但是xsstrike中的做法更加有意思。

生成payload

終於來到了重頭戲,生成payload是與前面兩個模塊息息相關的,也可以說前面的確定輸出以及過濾檢查模塊都是在爲生成payload收集信息,例如,我要定製一個輸出在屬性中的payload,那麼我首先要看我可以實用哪些特殊字符,其次我就要看這個屬性名是什麼,屬性值是否被引號包裹,如果屬性名是src,或許我可以生成一個payload像這樣:

javascript:alert(1);

如果屬性名爲name,並且屬性值被雙引號包裹,那麼我掃描器可能就需要生成一個像下面這樣的payload:

" onmouseover=alert(1);

當然這種payload是很難成功的,因爲太簡單了,所有我們生成的payload要具有一定的混淆過濾器的能力,比如用一些特殊的不可打印的字符替代空格,大小寫混合等等。

驗證payload

驗證payload,對於人來說可能就是看看瀏覽器是否彈窗之類的,但是對於機器來說可能就沒那麼輕鬆了,它還是需要去響應中去尋找我們的payload,如果我們的payload原模原樣的出現在了響應中,那麼基本可以確定漏洞確實存在了,就可以報告出來了


未完待續>>>

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章