[Rails] 解決 Reset Password 帶來的 token 洩漏問題

密碼重置是一個很常見的功能，通常都是發一個帶有 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 是表示「從哪連結進來到目前的網頁」，換句話說他會記錄你上一個連結是什麼。

能搞懂嗎？

我們假設一個情況：

1. 用戶在網站上按下「重置密碼」的按鈕，看到一條訊息告知請到電子郵箱裡面獲得連結。
2. 用戶在信箱裡，透過連結點擊了重置密碼的按鈕
3. 用戶來到了重置密碼的頁面
4. 用戶突然有問題想問客服，於是點開了右下角的第三方插件，呼叫客服
5. 客服系統後台收到用戶訊息，同時也拿到 HTTP header[referer] 了

這只是其中一種案例，那如果是打開頁面就自動執行的用戶行為蒐集呢？

所以駭客如果能拿到第三方服務的帳號，加上這個洩漏的可能，是不是很多用戶他都可以重置密碼了 XD？

Rails 中常用的 Devise 也有這個隱患存在，不過還沒修掉就是，可以參考 PR 裡面 owner 有提到暫時不修的原因。

Thoughbot 的文章提出兩種解法，我認為都不錯

1. 當用戶點擊網址後，Token 直接作廢，並生成一個新的 token 給當前的表單使用。雖然 referer 還有原本的 token，但不怕洩漏了，因為已經作廢。
2. 當用戶點擊網址後，在 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

這樣就修好這個隱患啦！

• Is Your Site Leaking Password Reset Links?