link: https://play.picoctf.org/practice/challenge/173?category=1&page=1
這題我一開始用 curl
,但是沒想到一直進入 302 FOUND
的循環,以下是我下的指令:
恩對,反正就是不能單純用 curl
來處理。
所以我就想,既然是要進行網頁的操作,我就乾脆改用 BurpSuite 來處理!
這邊我開啟 HTTP history
來研究數據的變化:
這邊我可以看到 Cookie 的字樣,然後我就來用攔截修改封包的方式來看看改動 cookie 會怎麼樣:
原本的封包。
將
Cookie: name=-1
改成Cookie: name=0
試試看的後續封包。
改完後的呈現結果。
恩…確定這招在這裡沒用…
然後就開始研究網頁內容。
這邊既然有 <input>
欄位,那也就代表有東西會輸入進去送,因此看了一下他的 source。
但是因為沒啥價值,所以我就不放圖了
接著打開了 dev tools 看一下網頁的狀況:
我隨便在 <input>
中輸入內容,看到網路狀況長這樣:
多了一個 search 的封包寄送,然後點進封包查看:
Ok,我這邊很確認這個 /search
的東西有一定的作用,但是重點在還不知道要輸入什麼進去。
這時候抱著死馬當活馬醫的心態輸入了他的 placeholder:
接著神奇的事情發生了:
然後看了一下 dev tools:
原本如果回答錯誤,他的 302 found
是導向 /
的,但是在回答了正確後,他就導向了 /check
這個 Url。
所以就檢查 /check
的封包:
然後發現了一件事情:
Cookie 的值竟然變成 name=0
了
大有可為大有可為,非常有機會可以用這個來試試看。
所以回到 BurpSuite 攔截封包,並把 cookie 改值送出試試看:
這邊我將原本是
name=0
的改為name=1
得到結果產生變化了!
這邊可以確認,他是用 cookie 來辨認要回傳的資料的!
所以就來用笨方法一個一個試吧!
中間過程太繁瑣,所以就不 show 出來,只知道我嘗試到 name=18
時終於吐出了 flag (終於啊,淚奔
這題我覺得非常有趣,活用了 cookie 的內容。同時我們也知道了一件事情:
如果你使用 cookie 作為驗證身份的手段,是會出事的!
沒錯,這題其實就是在做 Authentication 的內容。
尤其是老網站時常用 Cookie 來當身份驗證的工具,但是 Cookie 一旦被盜取,就會出問題。
不過說真的, JWT 令牌被盜取,應該也是同樣結果啦!
只是好處是 JWT 內部自有 expired 的機制,但是 Cookie 則仰賴伺服器端有沒有撰寫。
所以就看後續開發時怎麼選擇囉!
反正我現在都是用 JWT 居多。