Nic Lin's Blog

喜歡在地上打滾的 Rails Developer

[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

這樣就修好這個隱患啦!

參考資源

comments powered by Disqus