記一次COOKIE的偽造登錄

發現它的網址如此

通過信息收集—發現它的密碼規則如下（因重點是COOKIE的偽造登錄，故密碼規則就不放圖了，你懂的）

賬戶：xxxx

密碼:  Aa1xxxx

爆破一個弱口令的賬戶進去，發現是低權限，java寫的網址(java寫的一般涉及的都是越權，未授權之類的)

仔細搗鼓了許久，什么都沒有發現…

get請求，無明顯的越權操作….

正當毫無思緒的時候，換了個思路去想，如果能拿到高權限的賬戶，就可以發現進一步有哪些操作，如果去發下拿下賬戶是高權限，此時，看到這我陷入了沉思，一般這種情況都會暴露用戶名，再結合密碼規則，去看看，看能不能夠到管理員。

通過發現的用戶名，打算進行弱口令嘗試

但是突然發現它的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的偽造……

只撞到一個管理員權限..

現在高權限用戶拿到了，剛剛已經說了,存在未授權的漏洞，現在馬上試試，看能不能在賬戶管理這個地方是否有未授權..（發現不存在未授權，但存在COOKIE偽造）

注意，我在burosuit中通過查看匹配，來判斷是否能夠訪問成功。

當有cookie的時候

按道理來說，不應該如此，應該存在其他漏洞，于是我我就慢慢去刪除COOKIE找到最后端驗證的COOKIE，也就是COOkie的偽造是存在

后面的過程就是不停的偽造，管他什么未授權漏洞，還是COOKIE偽造，一鍋燴了，全部COOKIE偽造就好。

到此為止，這個簡單的系統就進去了。

總結思路：1.先是通過弱口令規則，發現存在未授權；2.再通過弱口令規則，找到管理員，進行繼續找危害大的未授權url；3.再尋找過程中，發現賬戶賬戶管理處存在不存在未授權，而是存在COOKIE的偽造；4.點到為止

換個網址，好家伙，還通殺

總結：1.Java類型的網站，感覺挖的更多是越權,未授權的這一塊；2.在測試過程中，每個點都不能放過；3.挖洞更多的是細心