在整改中,無法更新文章,難受啊...
記錄一次react的xss漏洞發現,比較有意思:
某個站:
直接輸入,直接把我跳轉到了404,猜測可能做了一些驗證:
嘗試多重編碼,發現都被轉義.網頁上也沒地方執行了
後來嘗試html實體義:
-直接請求,也被跳轉到了404,進行了二次url編碼,發現-掉落在網頁原始碼中可見,並且解析執行了
檢視原始碼很奇怪,奇怪點就是因為14個輸出的地方全部對<>這些進行了轉義:
那麼為什麼會觸發xss呢?
真正的觸發點:
<明明轉義了為啥還能觸發?div
class
="content desc"
>
***x testtest
yyyyyy
div>
全域性搜尋了下class名:
發現在js裡面呼叫了
), r.default.createelement("div",js裡面建立了div，設定class name然後設定資料,在body裡面這樣使用:
<這樣使用dangerouslysetinnerhtml是沒有安全風險的,但是在js裡面使用dangerouslysetinnerhtml是可能存在安全風險的,它會把實體編碼二次轉義回div
dangerouslysetinnerhtml
=} />
最終觸發xss攻擊. 通過這個xss讓我明白,一切輸出都是不安全的,都有被攻擊的風險,即使是有轉義,也可能被攻擊。也透露了乙個小技巧,輸出點有class="***",id="***"等的時候,可以全域性搜尋下屬性名,看看他是怎麼處理屬性的。
xss植入 記一次xss漏洞挖掘
最近碰到的xss比較少，記錄一下。測試xss漏洞，首先要確定輸入輸出點，再根據輸出的資料來確定目標 過濾以及轉義的是哪種字元，因地制宜。有輸入的地方便可能存在 各種 漏洞。測試發現，該處轉義尖括號，過濾alert，但未過濾雙引號，沒過濾雙引號一切都還好說。目標 過濾alert 可以用到的彈框函式還有...
記一次隱秘的XSS漏洞挖掘
前言在為某客戶 做滲透測試時發現乙個有趣的事情。當我訪問該 的某條鏈結時伺服器返回的是404頁面。看到這裡我當時就下意識的忽略它，但是後來又想了想這也不是完全沒有價值，畢竟中介軟體及其版本都出來了。於是上web神奇awvs，大概掃了半小時終於有發現。awvs結果顯示在 sys variable na...
記錄一次簡訊轟炸漏洞挖掘
簡訊轟炸漏洞一般分為兩種 1.對乙個手機號碼轟炸n次 2.對單個手機號碼做了接收驗證次數，但是可以對不同手機號傳送簡訊無次數限制 在漏洞挖掘中遇到個有意思的案例，寫篇文章分享出來。在接收簡訊處都有可能存在簡訊轟炸漏洞。輸入手機號然後接收簡訊 首先我會檢視響應接收和cookie中是否會返回正確的驗證碼...