iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 18
1
Software Development

Go Phishing!30 天用 Go 實作 Reverse Proxy 之釣魚大作戰系列 第 18

Day18-發 issue I(觀察篇)

今日目標

明明 cookie、header 都已經處理完了,為什麼還是不能發 issue 呢?今天的目標就是要找出到底是哪個環節出了問題

比較請求

先來觀察平常在 Github 發 issue 的請求長什麼樣子(下圖):看起來是個 POST 請求,請求中帶著一堆 cookie,Github 處理完之後會用 302 Redirect 讓瀏覽器跳轉到 issue 頁面

在自己架在 localhost 的 Phish Github 發 issue 也是發出 POST 請求、帶了一些 cookie,但卻直接被 Github 422 Unprocessable Entity 打回來QQ

眼尖的你有發現哪裡不一樣嗎(左圖成功、右圖失敗)?右邊發出去的 cookie 好像特別少欸,怎麼會這樣勒

到瀏覽器 Devtool > Application > Storage > Cookies 裡面比較一下到底少了什麼 cookie(左圖成功、右圖失敗)

發現我們自己架在 localhost 的 Phish Github 少了一個叫做 __Host-user_session_same_site 的 cookie

追查 cookie 來源

這個 __Host-user_session_same_site 看名字應該是在登入的時候 Github 該發給我們的號碼牌,來確認一下

??怪了,Github 明明有發給我號碼牌,但是瀏覽器收到卻沒有存起來

查了一下 MDN Set-Cookie 才發現原來只要是 __Host- 或是 __Secure- 開頭的 cookie 都必須帶有 secure 屬性,而且網站也一定要是 https,簡直就是加強版的 secure 阿

因為我們在 Day13 把 cookie 的 secure 屬性都刪掉了,但 __Host- 開頭的 cookie 又規定一定要有 secure 屬性,所以才會造成有看到 Set-Cookie 但沒有真的存到瀏覽器的情況

因為目前架在 localhost 的網站沒有 HTTPS,所以也沒辦法幫他加上 secure 屬性,那該怎麼辦勒

小結

今天發現了一個大問題:因為 cookie 名稱是 __Host- 開頭所以導致 cookie 沒辦法 set 到瀏覽器,但又沒辦法真的用 HTTPS,所以導致某些功能(發 issue)沒辦法正常使用,雖然這問題不太好處理,但還是有辦法的,大家也可以先想想看該怎麼辦


上一篇
Day17-轉發 HTTP header II
下一篇
Day19-發 issue II(實作篇)
系列文
Go Phishing!30 天用 Go 實作 Reverse Proxy 之釣魚大作戰30

尚未有邦友留言

立即登入留言