挖洞經驗|一個繞過某SRC廠商三處XSS過濾的payload

0x01 前言

在某次src的漏洞挖掘過程中，發現了一個payload繞過了三處xss過濾，個人覺得還是挺有意思的，所以記錄一下。

0x02 從一個被忽略的self xss說起

在某頁面信息如下，我決定對回復內容進行xss測試

插入一個<img/src=1>后可以看到標簽成功解析

繼續深入測試的時候卻發現了問題

我們的payload應該是觸發了xss防御機制無法提交成功，所以服務器返回501錯誤。

開始慢慢探測xss filter的規則

<img/src=1> 不攔截

<img/src=1 onerror=alert(1)> 攔截

所以首先想到可能是onerror一類的事件屬性被攔截，實際發現并不是

沒有攔截事件屬性，猜測是攔截alert，使用prompt和comfirm均被攔截

證明xss一定要彈窗嗎？并不是（雖然我的習慣是這樣），然而......

大部分標簽無法使用，還可以使用一個<a>標簽，嘗試之，em......，果然不出意外不可以

測試發現

攔截：

javascript:alert()、

javascript:''alert()"、

onerror=alert()、

onerror=''alert()"

不攔截：

javascript:aalert()

onerror=aalert()

證明規則不是攔截alert這個關鍵字，而是組合（猜測是正則匹配），峰回路轉，所以我們需要使用一個既不會觸發這個規則有可以正常執行的payload

首先想到的是混淆繞過過濾

nice~

通過進一步分析，發現該處是一個self xss，因為問題id參數是自己的，無csrf等其他漏洞輔助，而且數據POST提交無法change method，相當雞肋。

0x03 某處存儲型XSS

在對廠商進一步測試的時候，發現某站點編輯簡歷時的存儲型XSS，和上面的過濾規則一毛一樣，所以直接<img src=1 onerror=(alert)(/xss/)>

0x04 某處CSRF+存儲型XSS

在進一步，某站點附件上傳時

url參數直接拼接導致XSS，使用同樣的方式繞過xss fillter

此處是self xss 不過存在CSRF漏洞，組合即可，不再贅述。

0x05 總結

混淆繞過不是萬能的，但是有時候往往有意想不到的效果，而且有的可能不需要混淆繞過，可以嘗試一些字符和編碼，如onerror=a&Tab;lert()、onerror=al lert(1)等等，可以自己去摸索嘗試，而且混淆的方式有很多。