某SRC BypassXSS

點擊"藍字"關注，獲取更多技術內容！

聲明：

挖掘的案例均已提交至漏洞平臺並已經修複，本文僅限於技術討論與分享，嚴禁用於非法途徑。若讀者因此作出任何危害網絡安全行為後果自負，與本號及原作者無關。

先是在一個某SRC千萬級APP，摸到其論壇，瞎逛，啥都去點一遍，發現一個發錶感想的地方

嘗試打了一個<h1>whskxk</h1>whskxk，發送之後比較一下字體會進行變化，猜測此處存在XSS。

剛開始用svg  iframe標簽  form錶單 a標簽帶JavaScript，details ontoggle 嘗試攜帶xss的執行語句，發現發送之後全部被過濾掉，並且全部被過濾為空。

順帶一提，如果直接在發錶評論的文本框直接打payload，會被一個<p>標簽和<br>標簽包住，導致打入的payload會被以文本的形式輸出，這邊可以利用Burpsuite抓取請求包，把裏面的<p>和<br>標簽全删掉，注意要全删掉 不能就删個<br>標簽 不然上傳服務器的時候會請求格式錯誤。

後續嘗試了多種標簽 發現唯獨img標簽沒有被過濾掉，猜測應該是本來這個論壇就支持圖片插入，支持遠程加載圖片，導致讓我們有機可乘。如圖所示↓

嘗試打個<img src=1>，這個目的是為了看看系統有沒有判斷src來源必須是http協議或者https協議，結果顯而易見沒有進行來源判斷，前端成功顯示payload.

發現這些居然都沒過濾 直接簡單無腦打payload：<img src=1 οnerrοr=alert(1)>，發現onerror後面全部被過濾為空。

當時以為onerror被過濾，替換了oneload,onpageshow,onmouseover,onbounce,onstart等

Tips:onstart,onbounce當時這兩個本地調試的時候，就只有火狐能彈，chrome彈不出來。

當時第一感覺應該是空格的問題導致他們被分割 系統牛馬的讀取方式我也猜不到，於是嘗試性的去把src=1和onerror之間的空格改成+看看會不會解析。

payload：<img+src=1+οnerrοr=alert(1)>

居然發現！雖然onerror事件前面的+被沒解析為空格但是確切發現了是空格的問題，同時還發現了（）被url編碼了一遍

空格過濾+圓括號過濾！簡單有手就行.

為了萬無一失重組一下payload：<img/src=1/οnerrοr=alert`1`>，但是又發現這個src和onerror之間的/的又沒有被解析為空格。看到“1/οnerrοr=`1`”是整個雙引號包住了，當作一個整體成為了src的來源值，所以onerror事件不會被執行

小彩蛋：當時由於這個系統每天只能回帖15次 我找F12群裏的師傅們幫忙試幾個payload，

我一直在編輯裏面搗鼓畢竟沒次數了，後來發現甘栗釀編輯怎麼樣也彈不了，重新回複發帖就可以彈。這邊還過濾了alert但是Alert沒過濾 但話又說回來編輯功能點這邊Alert不會被解析所以導致編輯處彈不了窗。（其實還可以用別的彈窗事件，當是感覺Alert也會彈的，就沒去嘗試別的）

當時我這邊的思路就是利用“再去嘗試閉合掉，把前面的“和src=1後面的自己輸入轉義之後的”閉合，接著遇到了空格被正常解析 ，onerror後面的又被“”包住，且本地調試是包住帶著反引號也是可以執行的

當時發現這個回顯我有點迷糊所以本地調試了一下

發現是可以彈的，但是注意！我當時是在編輯裏面改的！不是直接重新發帖，回過頭發現這個payload 在發錶評論是可以彈出來的！！！

後來就在群裏討論 ，討論完就繼續試。突然一聲QQ提示音 打開一看尼瑪出xss了

當時看這個payload還是有點糊塗，仔細理解了一邊 和我自己當時琢磨的差不多 想去過濾為空重新組合一遍完整的，但是這個系統的過濾很奇葩 每當組合起來過濾之後的東西就不是自己想要的。同時由於自己在編輯裏面測 導致什麼都彈不了窗口。直到12點了 可以重新評論

打入自己剛開始在編輯處怎麼也彈不出來的payload:

<img/src=#\"οnerrοr=alert`whskxk`>成功彈窗。

我覺得刑，師傅們在測試的盡量彈console.log，由於我這邊可以編輯修改掉 我圖方便就直接在網頁彈框了。

投稿須知

         歡迎投稿        

投稿郵箱：[email protected]

投稿QQ：3200599554

黑客極客技術、信息安全熱點

安全研究分析
等安全相關的技術文章稿件通過並發布還能收獲200-800元不等的稿酬

戳“閱讀原文”體驗靶場實操