今天就要開始broken access control了，預計每天會寫一章，最後一天寫該怎麼防護，總計大概五天

Hijack session(工作階段劫持)是什麼?

由於HTTP協議本身是stateless，這代表每次刷新網頁時網頁都會將使用者當成新使用者，為了讓使用者能被網頁記住，會指派一個session ID來識別使用者，對使用者發送的封包內有set-cookie標頭以及一個身分驗證cookie，這個cookie常常會存在使用者端以及伺服器端，但這也衍生出了兩個問題

1. 受害者客戶端若遭到滲透(例如之前寫過的XSS)，那麼滲透者便能盜用受害者身分
2. 若這個身分驗證cookie並非隨機，或者生成演算法太過簡單，那麼也有可能讓滲透者得以預測並加以利用

這次的題目便是後者的情況

Webgoat A1 Hijack a session 號碼2(題1)

這題叫我們要自己找hijack-cookie的值，那麼我們就來試試看吧，先從F12看看

點了access後可以看到真的給了我們一串cookie，但只有一串我們也沒辦法找出規律，所以讓我們右鍵刪除這個cookie後再試一次看看

可以看到value分成了兩部分，左邊只是+1，右邊的數字雖然看不太出來，但也有變大的跡象，再試第三次看看

也是相同的情況，證明了我們的想法是正確的，同時，多發幾次封包後會發生這種情況，這裡開始使用burp suite的intruder，用null playloads來發封包

value左側跳過了一個數字，從326437900866072823直接跳到了326437900866072825
又因為右側數字基本上只會往上加，所以我們有一個猜測
被跳過的326437900866072824右邊的對應值應該在326437900866072823對應值和326437900866072825對應值之中，把右邊的對應值範圍做成字典表，使用fuff發送封包測試就能解這題了

然後....有點尷尬的是我不知道我這題甚麼時候解完的
因為我用ffuf發封包的時候完全沒有特殊資訊跳出來，但還是過了
我猜是收到有指定cookie的封包就算過了，不用自己去改瀏覽器的hijack cookie再點access，所以我不用知道確切的cookie是哪個，算僥倖過關了

明日內容: Broken access control 的Insecure Direct Object Reference