Cookies

link: https://play.picoctf.org/practice/challenge/173?category=1&page=1

問題

解法

初步嘗試

這題我一開始用 curl，但是沒想到一直進入 302 FOUND 的循環，以下是我下的指令：

curl -IL http://mercury.picoctf.net:27177/

恩對，反正就是不能單純用 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 居多。