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 (終於啊,淚奔

:clap: :clap: :clap:

結語

這題我覺得非常有趣,活用了 cookie 的內容。同時我們也知道了一件事情:

如果你使用 cookie 作為驗證身份的手段,是會出事的!

沒錯,這題其實就是在做 Authentication 的內容。

尤其是老網站時常用 Cookie 來當身份驗證的工具,但是 Cookie 一旦被盜取,就會出問題。

不過說真的, JWT 令牌被盜取,應該也是同樣結果啦!

只是好處是 JWT 內部自有 expired 的機制,但是 Cookie 則仰賴伺服器端有沒有撰寫。

所以就看後續開發時怎麼選擇囉!

反正我現在都是用 JWT 居多。