iT邦幫忙

2019 iT 邦幫忙鐵人賽

DAY 14
1
Software Development

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

Day14-HTTP Redirect I(原理篇)

前幾天把轉傳 Cookie 都做完了,但你以為這樣就真的可以登入了嗎?筆者我原本也以為這樣就可以了,想不到被 Go 的 HTTP Client 陰了。因為這部份要講比較久所以會分成兩篇,今天先講 HTTP Redirect 的觀念明天才實作

3XX Redirect

HTTP status code 裡面有一系列 3XX 都是用來重新導向的,其中最常見的是 301 Moved Permanently302 Moved Temporarily

  • 301 Moved Permanently

    這看名字就知道是永久的重新導向,像 google.com 會被導到 www.google.com,多了一個 www;或是 www.medium.com 會被導到沒有 wwwmedium.com,像這種永久的重新導向就會使用 301 Moved Permanently

  • 302 Moved Temporarily

    302 則是臨時的重新導向,譬如說很多網站在登入後會導到首頁,若密碼打錯就留在原本的登入頁,Github 也是這樣,這種需要判斷情況然後導向不同頁面的就會使用 302 Moved Temporarily

Location

但不管是 301 還是 302 重新導向,都 一定會有一個 Location 寫在 HTTP header 裡面,指的是要導去哪裡

像 Github 在登入後要把使用者導回首頁,那 Location 就會寫 https://github.com,如果我們放任不管那使用者登入後就會導回真正的 Github,這可不行阿,當然是要想盡辦法要把使用者困在釣魚網站裡面XD

Google 的話也可以打開 Devtool 看一下,會看到他把 google.com 導到 www.google.com,而且如果是 301 Moved Permanently 的話你的瀏覽器就會記住,下次你再輸入 google.com 時他就會自動導過去不用再問 Google

目前的問題

在真正的 github 登入的時候,Github Server 會回傳 302 Redirect,然後把網址跳轉到 https://github.com,順便給瀏覽器一個 user-session 的 cookie

但在我們自己的 Phish Github 登入時卻還是回傳 200 OK,而且也沒有拿到 user-session 的 cookie

看到這裡應該知道問題出在哪裡了吧,因為我們的 reverse proxy 沒有把正確的 status code 轉傳給瀏覽器,導致瀏覽器不知道要重新導向,這也是我們明天要實作的部份

小結

今天的內容比較輕鬆,只有簡單帶過 3XX RedirectLocation 的觀念,我想應該大家都有看懂,有任何問題的話很歡迎在下面留言,沒問題的明天就要開始實作重新導向的部份囉


上一篇
Day13-Cookie & 登入 III(實作篇)
下一篇
Day15-HTTP Redirect II(實作篇)
系列文
Go Phishing!30 天用 Go 實作 Reverse Proxy 之釣魚大作戰30

尚未有邦友留言

立即登入留言