01
發現它的網址如此
通過信息收集—發現它的密碼規則如下(因重點是COOkie的偽造登錄,故密碼規則就不放圖了,你懂的)
帳戶:xxxx
密碼: Aa1xxxx
02
爆破一個弱口令的帳戶進去,發現是低權限,Java寫的網址(java寫的一般涉及的都是越權,未授權之類的)
03
仔細搗鼓了許久,什麼都沒有發現…
get請求,無明顯的越權操作….
正當毫無思緒的時候,換了個思路去想,如果能拿到高權限的帳戶,就可以發現進一步有哪些操作,如果去發下拿下帳戶是高權限,此時,看到這我陷入了沉思,一般這種情況都會暴露用戶名,再結合密碼規則,去看看,看能不能夠到管理員。
05
通過發現的用戶名,打算進行弱口令嘗試
但是突然發現它的url有點怪…
http://xxxxx.xxxxx.edu.cn/xxxxxx/frame.htm?title=&url=http://xxxxx.xxxxx.edu.cn/xxxxxx /common/user_xxxxxx/&plug_in_js=&system_owner_app=/xxxxxx&_system_todo=newReceiver(true)
就直接馬上想到未授權這一塊….
直接掏出其他瀏覽器,不進行登錄,進行進行訪問..
好傢夥,直接未授權,既然未授權存在,那麼這個系統在web端多半就千瘡百孔,現在的目標就是拿到高權限的用戶,然後找到它的有價值的url直接未授權即可,然後再測試cookie的偽造……
只撞到一個管理員權限..
06
現在高權限用戶拿到了,剛剛已經說了,存在未授權的漏洞,現在馬上試試,看能不能在帳戶管理這個地方是否有未授權..(發現不存在未授權,但存在COOKIE偽造)
注意,我在burosuit中通過查看匹配,來判斷是否能夠訪問成功。
當有cookie的時候
07
按道理來說,不應該如此,應該存在其他漏洞,於是我我就慢慢去刪除COOKIE找到最後端驗證的COOKIE,也就是COOkie的偽造是存在
後面的過程就是不停的偽造,管他什麼未授權漏洞,還是COOKIE偽造,一鍋燴了,全部COOKIE偽造就好。
到此為止,這個簡單的系統就進去了。
08
總結思路:1.先是通過弱口令規則,發現存在未授權;2.再通過弱口令規則,找到管理員,進行繼續找危害大的未授權url;3.再尋找過程中,發現帳戶帳戶管理處存在不存在未授權,而是存在COOKIE的偽造;4.點到為止
換個網址,好傢夥,還通殺
總結:1.Java類型的網站,感覺挖的更多是越權,未授權的這一塊;2.在測試過程中,每個點都不能放過;3.挖洞更多的是細心