2010-10-28 32 views
3

特別是,我寫了一個Rails應用程序,我在其中使用默認(在Rails 2.3.5)CookieStore會話存儲,我發現了一個奇怪的問題。如何防止Rails用戶意外認證爲錯誤的用戶?

我自己和其他一些人一直在使用這個網站幾個星期,我們每個人都有一個基於用戶名和密碼的登錄(每個用戶都註冊了他們自己,並且將(鹽漬和散列)數據存儲在數據庫中)。我將用戶標識存儲在Rails session對象中(並且因此存儲在瀏覽器和服務器之間來回傳遞的cookie中)。這裏

很重要的一點:因爲這是一個內部網站,我設置的Cookie活路了長達2周,以避免登錄所有的時間用戶。

今天,我重新設置數據庫,抹所有用戶的記錄(以及所有其它數據,故意)。一些用戶開始重新註冊自己,然後一位用戶發現,自他們第一次進入網站後,他們自動以不同的用戶身份登錄!

我想我能看到爲什麼會這樣:服務器從用戶的瀏覽器通過用戶ID現在在我的數據庫匹配不同的用戶記錄。我最初的想法是「哦,親愛的,我沒想到那個!」但我越想越多,我意識到這可能是預期的行爲。

我知道我可以改變我的Rails應用程序到用戶ActiveRecordStore,但我這樣做,我想確保我明白這是怎麼回事之前。具體來說,使用CookieStore會話和讓會話保持活動一段時間的組合是否真的會造成這樣一個巨大的安全漏洞?或者我錯過了什麼? session_id應該在這裏提供一點安全性嗎?

回答

1

您在此處遇到問題的最簡單解決方案是在重置數據庫時更改了cookie名稱。 cookie的名稱應該是配置/初始化/ session_store.rb

ActionController::Base.session = { 
    :key   => '_your_app_session_v2', 

你也可以改變的祕密,但如果他們要求該網站與舊Cookie可以爲您的用戶錯誤。

+0

這看起來很簡單,我會在將來編寫的基於CookieStore的Rails應用程序中使用它。 – Ben 2010-10-29 11:52:24

4

此安裝中的一個大安全漏洞不是cookie長度,而是將user_id設置爲cookie。這意味着任何登錄到您網站的人都可以通過更改該cookie來以任何其他方式登錄!黑客只會順序遍歷user_id,登錄並查看是否有任何他們想竊取或濫用的內容。

如果你想推出自己的認證,試試這個來代替:「令牌」字符串字段添加到您的用戶表。當有人登錄時,將此令牌設置爲一組隨機的數字和字母,並將作爲cookie傳回給用戶。令牌應該至少有32個字符,字母數字,大寫和小寫。現在

當用戶進入一個頁面,帳戶是由散而不是他們USER_ID擡頭。值的是哈希值更難猜測,並且永遠不會重複。當您重置數據庫時,您的user_id實際上會重複,從而導致人們彼此登錄。

UPDATE

@shingara是正確的cookie存儲確實已經處理安全的一部分,我的錯誤。因此,user_id混合是一次性的,因爲您重置了數據庫。這不是您在生產環境中會遇到的問題,除非您再次重置數據庫。如果重置是有有的可能性,那麼仍然按照我的建議進行令牌創建。否則,你沒事。

+0

的代碼片段,我想的user_id是不是cookie的解決它。在會話中存儲在cookie中。所以它被加密了。黑客無法輕易找到user_id。 – shingara 2010-10-28 15:56:24

+0

這種情況也可以抵達。 – shingara 2010-10-28 15:57:18

+0

我有點困惑 - 我(或某人)是否暗示餅乾長度是安全漏洞的一部分?至於修復,是的,我可以使用'ActiveRecordStore'作爲我的會話。 – Ben 2010-10-29 11:56:23

0

只有當您擁有2個擁有相同user_id的不同用戶時,您的情況纔會到達。所以,如果你將user_id定義爲unique,這是不可能的。

另一種情況是,您可以在會話中添加一個用戶使用唯一鍵的散列。當你檢查會話時,你會得到user_id並檢查user_token是否相同。如果沒有,則用戶未被授權。

+0

爲什麼這樣downvote:'( – shingara 2010-10-28 16:37:26

+0

在數據庫中從來沒有兩個用戶具有相同的ID,在一個瀏覽器中保存的cookie指的是一箇舊的ID,全部是 – Ben 2010-10-29 11:46:43

+0

,第一個數據庫中的id爲1的用戶和另一個用戶在你重新設置數據庫之後,id爲1,第一個id爲1的用戶在新數據庫中被認證爲id爲1的用戶 – shingara 2010-10-29 11:56:51

0

謝謝你所有的迴應。他們都以某種方式回答了我的問題:是的,我的設置(以及在擦除用戶後未設置新的會話密鑰)會造成安全漏洞。

許多Rails教程都提倡這種設置,並沒有提到所有你需要的是用你的cookie來猴子作爲另一個用戶的完全身份驗證。

因此,要總結,我問的問題,因爲我找不到任何討論CookieStore會議+長Cookie有效期的危險,我發現令人驚訝所以以爲我可能失去了一些東西明顯。