最近呢, 也是基礎漏洞學的差不多了, 就在edusrc上面實戰, 剛開始搞一些資訊泄漏啥的, 提交了十幾個, 結果就他娘的通過了一個. 咱也就不碰資訊泄漏了, 沒得意思.
關于這個學校測驗時也是有坑的, 剛開始找到的統一平臺地址登錄過之后是廢棄的, 我當時就以為這后臺是不是不用了, 然后過了一兩個小時, 我在做資產搜集的時候, 又發現了一個一樣的登錄點, 但是目錄不一樣了, 才發現這狗日的資料是通用的, 但是修改后跳轉的登錄頁面確實假的.
第一個漏洞: 修改密碼判斷不嚴謹.
這個就是常說的邏輯漏洞, 修改用戶密碼. 功能點是在首頁的忘記密碼處,
這個漏洞利用還是有條件的, 需要學號+系結的郵箱. 因為我是有個朋友在這個學校上學, 我就通過: site: xxx.edu.cn "我朋友的名字"找他了他的學號. 在通過他的QQ確定了郵箱. 當然了, 這個程序我是沒有聯系他的啊.
利用方式也很簡單, 選擇驗證方式-> 確認賬戶, 確認賬戶的時候就把學號+系結的郵箱輸入進去就行了, 進入到認證的時候, 發送驗證碼的時候抓包吧收件郵箱改成自己的就可以了.
在輸入完驗證碼點擊下一步的時候又進行了一次郵箱的修改, 這個時候后臺判斷的應該是發送得郵箱+驗證碼, 所以還是要把自己的郵箱寫上去.
后面就不需要在修改了, 正常輸入新密碼就可以了, 修改完成以后就是之前說的, 跳轉到了廢棄的那個登錄頁, 他媽的. 以后長記性了
第二個漏洞: 前端給的權限太大. 修改回傳包. 這個就是任意密碼修改了, 想改誰就改誰.
算是第一個漏洞的延伸吧, 我在之前的基礎上又測了一下, 測驗了一下登錄成功的回傳包和失敗的回傳包, 看一下吧
登錄成功的回傳包
登錄失敗的回傳包
我是想做直接越權登錄的, 但是這個里有一個loginId無法繞過去, 因此無法正常顯示登錄成功的內容. 但是這里發現了一個叫isFirstLogin的值, 在他的登錄頁又看到了第一次登錄會強制修改密碼, 這里回傳的false, 也就是說不是第一次, 那要是改成true呢?
{ "isBindPhoneFlag":true, "loginId":"0d288066c83211eb9f2c55dbec8ac3d2", "isFirstLogin":false,
"phone":"************", 手動打碼 "success":true, "username":"21914101016" }
這里我是借鑒登錄成功的那個包, 內容都是亂寫的, 主要是在isfirstlogin, 成功跳轉到首頁密碼修改.
這里就算是結束了, 前面說的這玩意給的權限太大了, 你說你把修改密碼這個大的權限放在前端干嘛, 其實這里完全還可以再次擴大, 很明顯, 修改密碼是有一個介面的, 而這個介面沒有做任何判斷, 因此, 在修改密碼提交的時候, 還可以抓個包
這里嘗試一下隨便修改學號, 也是可以修改成功的, 這種介面沒有絲毫的判斷, 不知道該怎么去形容了.
總結一點: 細心細心, 還是他媽的細心. 什么點都測一下, 回傳包的內容都看一下, 可控的引數, 回傳包感覺有問題的引數. 都改改試試看, 總會有意想不到的識訓.
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/470617.html
標籤：其他
上一篇：CVE-2022-22947 Spring Cloud Gateway 遠程代碼執行漏洞復現
下一篇：java反序列化-URLDNS鏈