2009-08-30 158 views
7

我想使用cookies /會話創建登錄系統,但我不確定它們具有哪些安全性。登錄系統(PHP)Cookies和會話

通過會話,如果「登錄」設置爲「是」,我可以相信嗎?用戶是否能夠改變它返回的內容?我應該只存儲加密的密碼並在每個頁面上檢查它嗎?

有了cookies,我需要檢查諸如mysql注入之類的東西嗎?

這可能聽起來像初學者的東西,但如果有人能爲我澄清它真的很有幫助。在此先感謝您的回覆!

回答

7

如果設置了會話變量,用戶不能直接更改它,除非他們劫持了另一個會話cookie。

你主要需要注意的是共享主機,你的會話數據是不安全的(通常其他網站可以看到它)。

也值得注意的是,cookie數據也不安全。不應該依賴於不應依賴表單數據的相同方式(不管客戶端驗證告訴您什麼)。

你最好使用口令的做法是:

  1. 儲存於散列形式,優選SHA1(首選)或MD5(第二選擇)數據庫中的密碼;
  2. 當您收到用戶密碼時,請對其進行加密並根據存儲在數據庫中的內容進行檢查;
  3. 在用戶會話中設置登錄用戶名;
  4. 在某段時間(即使是它的日子)之後終止cookie,而不是永久持續;和
  5. 如果可能,請使用安全連接(HTTPS不是HTTP)。 SSL證書很便宜。
+0

這是否意味着我應該檢查每個加載頁面上的用戶名和密碼? 如何保證密碼數據庫和加密方法的安全? – 2010-05-13 03:14:52

+1

@Grue不只當他們登錄時,但你需要一個明智的失效政策。不同的IP地址,給定的時間長度,不活動的時間長度等等。無論您保護的是什麼(例如,銀行網站對於另一個您只是對視頻發表評論的銀行網站有不同的安全考慮因素),都是有意義的。 – cletus 2010-05-13 04:08:43

+3

這個答案中有些相當過時的東西。不要使用SHA1或MD5的密碼:http://stackoverflow.com/questions/1581610/how-can-i-store-my-users-passwords-safely – 2012-02-24 12:42:18

3

經驗法則:不要相信用戶輸入。 Cookies是用戶輸入,存儲在cookie中的會話ID是用戶輸入,http頭是用戶輸入 - 這些事情必須三重檢查每一個可能的事情。另一方面,會話數據存儲在服務器上,所以如果不存儲在/ tmp中,它或多或少是安全的。

會議授權最流行的設置之一是:會話ID存儲在cookie中,其他所有內容(包括密碼)都存儲在會話中。根據cookie中的id開始會話後,您應該從會話數據中獲取用戶標識,然後檢查存儲的密碼是否仍然有效。

0

的任何和所有的用戶輸入需要進行審查和宗教消毒,無論是GET和POST數據,cookie數據..

要回答你的問題,如果存儲在會話變種登錄狀態是安全的,答案是是的。只要記住要消毒用戶發送給你的所有內容,不管它應該有多安全。

5

正如這裏的幾個人所說,不要相信用戶輸入 - 永遠。通過消毒您的輸入,尤其是用戶名&密碼字段,有助於避免SQL注入攻擊。

對於一切美好&神聖不存儲在cookie中用戶名或密碼,他們送回&來回在每次請求和任何人觀看串流服務器可以搶奪數據...那麼你在很大的麻煩。

下面是你應該閱讀的會議一對夫婦的文章,安全性和哈希 - 只要你的散列密碼的SHA1或MD5是不夠的,鹽他們,使他們更強大。沒有不可穿透的安全性 - 即使你做了一切正確的事情都有人可以打破它 - 這是不可避免的。你的工作就是讓事情儘可能地破壞/利用。

參與闖入你的網站上的更多的工作,更有價值的內容必須是值得的。你的工作是勸阻惡意用戶。

這篇文章對您的訪問者創造獨特的指紋一些不錯的信息,有助於使會話劫持更​​加困難 - PHP Security Guide: Sessions

基本密碼本文討論散列&鹽析技術 - Password Hashing

這是並不意味着所有的事情都結束 - 你可以做一個職業,做安全等等,但他們是一個很好的起點。這裏有人可能會指出更好/更高級的文章,但我個人發現這些有助於支持我的代碼。

2

一個好的做法是使用存儲3個變量。一個用於登錄,一個用於用戶名,一個用於隨機生成的散列(當它們與其他用戶信息一起登錄並存儲在數據庫中時生成)。這樣,如果他們改變他們的用戶名可被存儲在他們的餅乾,它不會匹配這是爲該用戶產生的,當他們登錄的一個

示例:cookie數據可能是: LOGGED_IN = TRUE; user ='admin'; sessionid = [隨機生成的id(我通常只是md5,是我創建的一個隨機生成的詞)]

每次登錄時,都會生成一個新的sessionid並存儲在數據庫的自己的字段中。現在,如果我要更改我的cookie信息並將用戶變量更改爲'user'(這可能是另一個用戶,他們可能會嘗試使用hi-jack)。 sessionid將不再與第二個用戶的匹配,登錄將被拒絕。

下面是一個簡單的例子,我從一個CI項目幾個星期前,我在努力偷:

function logged(){ 
$logged_in = $this->session->userdata('logged_in'); 
if($logged_in){ 
    $userid = $this->session->userdata('userid'); 
    $sessionhash = $this->session->userdata('hash'); 

    $this->db->where('id', $userid); 
    $this->db->where('hash', $sessionhash); 
    $query = $this->db->get('members'); 

    if($query->num_rows == 1){ 
    return TRUE; 
    }else{ 
    return FALSE; 
    } 
} 
}