密碼重置是一個很常見的功能，通常都是發一個帶有 token 的連結來讓用戶把密碼重置，也因為有帶了 token，我們系統才可以知道「現在在重置密碼的人是誰」。
所以你有可能拿到一個連結長這樣
http://mywebsite.com/resource/password/edit?reset_password_token=a1b2c3d4
因為系統是認網址後面的 token 去找出要把哪一個用戶的密碼重置，也因為系統不會認人，所以當這個連結被駭客所取得，那就可以改成他想要的密碼，進而登入竊取資訊及操作了。
Token 是如何洩漏的，你知道 HTTP header 嗎
但其實我們無意間將這個訊息透露給其他第三方服務了，在此之前，我們可以先瞭解第三方如何收集數據來源。
如果你有用過一套不錯的客服系統「Intercom」就會知道，每個用戶在點開對話視窗後，我們從第三方系統裡面可以看到用戶的 IP、當前正在瀏覽的網頁等等資訊。
那是因為第三方服務在收集資訊時會參考 HTTP header，其中就包括了這一個資訊 「Referer」(題外話：Referer 的正確英語拼法是 referrer。由於早期 HTTP 規範的拼寫錯誤，為保持向下兼容就將錯就錯了。)
這個 referer 是表示「從哪連結進來到目前的網頁」，換句話說他會記錄你上一個連結是什麼。
能搞懂嗎？
我們假設一個情況：
- 用戶在網站上按下「重置密碼」的按鈕，看到一條訊息告知請到電子郵箱裡面獲得連結。
- 用戶在信箱裡，透過連結點擊了重置密碼的按鈕
- 用戶來到了重置密碼的頁面
- 用戶突然有問題想問客服，於是點開了右下角的第三方插件，呼叫客服
- 客服系統後台收到用戶訊息，同時也拿到 HTTP header[referer] 了
這只是其中一種案例，那如果是打開頁面就自動執行的用戶行為蒐集呢？
所以駭客如果能拿到第三方服務的帳號，加上這個洩漏的可能，是不是很多用戶他都可以重置密碼了 XD？
Rails 中常用的 Devise 也有這個隱患存在，不過還沒修掉就是，可以參考 PR 裡面 owner 有提到暫時不修的原因。
Thoughbot 的文章提出兩種解法，我認為都不錯
- 當用戶點擊網址後，Token 直接作廢，並生成一個新的 token 給當前的表單使用。雖然 referer 還有原本的 token，但不怕洩漏了，因為已經作廢。
- 當用戶點擊網址後，在 controller 中把 params 的 token 塞給 session ，並且在直接 redirect_to 自己，把 referer 洗掉。（這裡建議不要把 session 存在 cookie 內）
雖然還有 meta tag no-referrer 可以用，但我覺得這不是 view 的職責就不推薦了，並且會埋下不能用 redirect_back 的問題。
Devise 修正的實際作法，覆寫重置密碼的 action 如下 (參考如何客製化 devise controller)
class Users::PasswordsController < Devise::PasswordsController
def edit
if params[:reset_password_token].present?
session[:reset_password_token] = params[:reset_password_token]
redirect_to edit_user_password_path
else
self.resource = resource_class.new
set_minimum_password_length
resource.reset_password_token = session[:reset_password_token]
end
end
end
這是上面第二種解法，當用戶進來 /resource/password/edit?reset_password_token=abcdef 時，會在塞完 session 後跳到 /resource/password/edit
這樣就修好這個隱患啦！