2010-08-20 60 views
8

我在cookie中使用2個變量(7天過期),這是用戶ID和散列。哈希是用戶代理和用戶標識的sha1編碼。在這種情況下,一些黑客可以登錄誰是知道被盜的cookie的瀏覽器。我應該遵循哪種方式或哪種做法最適合記住我的安全問題?記住我的最佳做法功能

+0

相關:http://stackoverflow.com/search?q=php+session+hijacking – 2010-08-20 13:47:46

+0

只要可能,您應該重新使用現有的身份驗證框架,因爲它確實很複雜。例如,看看https://github.com/delight-im/PHP-Auth – caw 2016-09-21 02:53:03

回答

6

雖然你可以散列爲user_id和SECRET_KEY,誰攔截這個cookie可以登錄到您的應用程序。除此之外,你可以做到這一點,以便你記得我的餅乾很快就會過時。沒有人喜歡陳舊的餅乾。

您可以將每個用戶上次訪問的時間戳存儲在數據庫和cookie中。每次您閱讀cookie以將用戶登錄時,都會檢查兩個時間戳是否匹配。如果他們不這樣做,否認用戶。如果他們這樣做,更新時間戳。

使用此方法,只要您的用戶返回您的網站,所有舊的Cookie就會過時。一個已經攔截cookie的黑客現在有一個毫無價值的陳舊cookie,因爲他不知道當前cookie中的確切時間戳。當然,黑客可以利用一個新的cookie,他希望直到用戶再次登錄之多。

//check for cookie 
if(isset($_COOKIE['remember_me'])) { 
    // get hash and time stamp from cookie 
    $hash = substr($_COOKIE['remember_me'],0,40); 
    $last_visit = substr($_COOKIE['remember_me'],41); 

    // query your db with $hash and $last_visit 

    // if hash and time stamp match up 
     // log in 

     // store the current time stamp in a variable to use for both 
     $time = date("Y-m-d H:i:s"); 
     // update the time stamp in your cookie 
     $cookie = $pass . "-" . $time; 
     setcookie('remember_me', $cookie, time()+60*60*24*100, '/'); 
     // update the time_stamp in your database 
    else { 
     // remove the remember me cookie 
     setcookie('remember_me', '', time()-42000, '/') 
    } 

這種方法提供了安全少量,並且當然應該沿着在其他的答案提出端的方法使用。散列鍵應該存儲在cookie中。記住我的cookie不能完全安全,所以需要重新輸入密碼才能對高度敏感的數據或應用程序功能進行任何其他訪問。

我還建議給你的cookie命名除了'remember_me'之外的東西,使它更難找到。雖然它不會增加很多安全性,但是如果有的話,命名您的cookie'ht33424'只要命名爲'remember_me'或'hack_me'即可。

+0

對不起,但我不認爲我喜歡這個答案,除非我誤解它的邏輯,這依賴於用戶在黑客有時間複製並執行頁面之前加載新頁面。在真正的用戶會話結束時,存在劫持的大窗口,即使在會話期間,在頁面加載之間也不應太難。這會爲真正的用戶創建不尋常的頁面行爲。重命名cookie變量名稱是安全的,因爲它隱藏並浪費時間。 (續) – 2010-08-23 09:08:26

+0

......這可能是另一個層面,但一個堅定的黑客不會被它感染。由於我上面提到的原因,它不是100%安全的。對於敏感和潛在的破壞性訪問敏感信息和功能,我不會推薦這種方法作爲100%安全的解決方案,只是一個小小的改進。 – 2010-08-23 09:10:34

+0

對於一個確定的黑客來說,沒有任何方法是100%安全的。正如你所說,這實際上只是一個嘗試讓我們更接近100%的層。這意味着與其他方法一起使用,其中許多方法在其他答案中提供。散列鍵肯定應存儲在cookie中,並且需要重新輸入密碼才能更多地訪問敏感信息和功能。 – SomewhereThere 2010-08-23 12:58:53

0

就我個人而言,我創建一個隨機散列並將其存儲在「記住我」表中。該表還具有用戶代理,用戶標識和IP地址。每次我通過記憶功能重新登錄用戶時,都會檢查兩者。如果用戶手動註銷,我只需從表中刪除該行。然後,如果他們再次登錄,它會創建一個新的隨機哈希。實際上沒有辦法與記住我的系統來嗅探數據包(除非您使用HTTPS only標誌設置的安全cookie)。因此,請使用與HTTPS專用Cookie的安全連接。如果你不能,那麼至少使隨機散列,所以如果它被發現,你至少可以生成一個新的哈希來殺死該登錄...

+0

小心解釋-1? – ircmaxell 2010-08-20 14:18:26

+0

不是我,但我總是對這樣的執行保持警惕,因爲它假定像user agent和ip這樣的變量在常常不是常量時是常量。我不會將此定義爲解決方案,但更多的解決方法是 – 2010-08-20 14:37:24

+0

。但是在缺乏HTTPS cookie的情況下,是否真的有更好的方法來驗證源代碼? – ircmaxell 2010-08-20 14:40:10

0

您最終可以使用會話來存儲用戶狀態。但是,持續會話很長時間會導致同樣的問題,會話ID將被盜用。您可以將cookie信息與其他瀏覽器或IP地址一起加入,但當用戶沒有靜態IP時會導致問題。

無論如何,持有會話ID更安全,只需將用戶的sha1密碼輸入到cookie即可。

+0

幸運的是,OP沒有談論密碼:)但是,會話ID在這裏可能很有用。 – Piskvor 2010-08-20 14:00:04

+0

長時間運行會話幾乎總是一個壞主意。它們打開了特定DOS攻擊的大門,因爲您可以佔用非微不足道的存儲空間,因爲PHP在達到時間限制之前無法GC會話。在某些情況下,它是必要的,但大多數情況下它不是一個好主意...... – ircmaxell 2010-08-20 14:04:15

0

HMAC

我通常做這種方式,所以我沒什麼可存儲上的數據庫或類似的服務器端。

你必須生成隨機字符串,成爲你的「祕密密鑰」,你必須在服務器端存儲(可能在一個配置php腳本作爲常量),你永遠不會告訴任何人。我會叫這個密鑰SECRET_KEY

那麼你的cookie必須設置兩個值:

  • USER_ID:中USER_IDSECRET_KEY一個安全的加密哈希:這將讓自動登錄
  • HASH用戶的用戶ID。所以,例如,md5(USER_ID . "-" . SECRET_KEY)。 (與md5不同的東西,比如sha1或sha256是首選)。

因此,您的最終cookie可能是:USER_ID:HASH

然後,當你要檢查一個cookie是一個真正的記得我的cookie,你必須這樣做:

function isCookieGenuine($cookie_value) { 
    list($value, $hash) = explode(':', $cookie_value, 2); 

    if (md5($value . "-" . SECRET_KEY) == $hash) 
    return true; 
    else 
    return false; 
} 

的一點是,只有你可以生成通過此檢查,因爲一個哈希hash不僅需要USER_ID,還需要SECRET_KEY,這是服務器以外的人所不知道的! :)

正如評論指出的,你可以通過使用hash_hmac功能在PHP> = 5.1.2做到這一點:http://us.php.net/manual/en/function.hash-hmac.php

+1

太糟糕的數組解引用在PHP中不起作用(它僅在trunk中實現)。所以你可以改爲'list($ value,$ hash)= explode(':',$ cookie_value,2);'。如果你爲每個用戶實施一個不同的「祕密」,那麼它對安全可能會更好(因爲一次祕密的妥協不會爲每個用戶打開大門)。呵呵,PHP有一個內置的['hash_hmac'函數](http://us.php.net/manual/en/function.hash-hmac.php)來做這件事... – ircmaxell 2010-08-20 14:07:23

+0

@ircmaxell,+ 1爲您的評論(我開始忘記這些事情......我不再寫PHP了:))。我正在整合你的提示。我不同意爲每個用戶創建不同的祕密。雖然這顯然更安全,但我認爲在這種情況下,優勢很小。 – 2010-08-20 14:10:11

1

你可以簡單地設置到期日期,再加上一年的cookie,但是在所有敏感區域都有一個輸入密碼字段,就像amazon使用的實現一樣。被劫持的cookie將授予訪問權限,但購買或修改任何個人要求重新輸入的密碼。

「記住我」表的問題在於,如果黑客可以訪問此表,他可以創建並登錄儘可能多的帳戶。你可以爭辯說它加強了記住我的功能的安全性,但它需要權衡軟化膝蓋安全區域的風險。