可能重複：
What do I need to store in the php session when user logged in?PHP會話足夠安全以便自己登錄嗎？
我想用PHP會話登錄用戶一旦我驗證他們的身份，我想他們的USER_ID和has_logged_in保存在session中。要驗證他們是否已登錄，我會檢查他們的用戶標識是否已設置，並且has_logged_in爲true。偶爾，我會通過session_regenerate_id（true）重新生成會話ID。這是否足夠安全，還是必須採取進一步措施來防止劫持和其他會話安全漏洞？
爲了瞭解如何讓你的會話的安全性，您必須首先了解會議是如何工作的。
讓我們看看這段代碼：
session_start();
只要你調用，PHP將尋找一個名爲PHPSESSID（默認）的cookie。如果沒有找到，它會創建一個：
PHPSESSID=h8p6eoh3djplmnum2f696e4vq3
如果被發現，它需要的PHPSESSID值，然後加載相應的會話。該值被稱爲session_id。
這是客戶唯一知道的東西。無論您添加到會話變量中的是什麼，都會保留在服務器上，並且永遠不會傳輸到客戶端。如果您更改$_SESSION的內容，該變量不會更改。它一直保持不變，直到你摧毀它或超時。因此，嘗試通過哈希或其他方式混淆$_SESSION的內容是沒有用的，因爲客戶永遠不會收到或發送該信息。
然後，在一個新的會話的情況下，您將設置變量：
$_SESSION['user'] = 'someuser';
客戶將永遠不會看到這些信息。當惡意用戶盜竊的其他用戶的session_id可能出現
一個安全問題。如果沒有進行某種檢查，他可以自由冒充該用戶。我們需要找到一種唯一標識客戶端（而不是用戶）的方式。
一個策略（最有效）涉及檢查開始會話的客戶端的IP是否與使用該會話的人員的IP相同。
if(logging_in()) {
$_SESSION['user'] = 'someuser';
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
}
// The Check on subsequent load
if($_SESSION['ip'] != $_SERVER['REMOTE_ADDR']) {
die('Session MAY have been hijacked');
}
與策略的問題是，如果一個客戶端使用負載平衡器，或（在持續時間長會議）的用戶具有動態IP，它會引發假警報。
另一種策略是檢查客戶端的用戶代理：
if(logging_in()) {
$_SESSION['user'] = 'someuser';
$_SESSION['agent'] = $_SERVER['HTTP_USER_AGENT'];
}
// The Check on subsequent load
if($_SESSION['agent'] != $_SERVER['HTTP_USER_AGENT']) {
die('Session MAY have been hijacked');
}
該策略的缺點是，如果客戶端升級它的瀏覽器或安裝插件（一些添加到用戶代理），用戶代理字符串將會改變，並且會觸發虛假警報。
另一種策略是對每個請求旋轉session_id。這樣，理論上session_id停留時間不足以被劫持。
if(logging_in()) {
$_SESSION['user'] = 'someuser';
$_SESSION['count'] = 5;
}
// The Check on subsequent load
if(($_SESSION['count'] -= 1) == 0) {
session_regenerate_id();
$_SESSION['count'] = 5;
}
您可以根據需要合併這些策略中的每一種，但是您也可以合併這些缺點。
不幸的是，沒有解決方案是傻瓜式的。如果您的session_id受到損害，那麼您已經完成了很多工作。以上策略只是權宜之計。
只是我的看法，只要你不需要訪問一個數據庫，需要它的用戶名和密碼，它的安全性就足夠了。如果您打算存儲該用戶標識以訪問您必須知道的SQL注入漏洞，我認爲您知道這些。
使用它只是爲了像你提到的一個條件足夠安全。那多數民衆贊成我用什麼。
您不需要存儲'has_logged_in'，只需使用'$ _SESSION = array（）;'將用戶登出即可。 – 2012-03-06 03:50:00
不是沒有SSL – Petah 2012-03-06 03:57:02
你能說說SSL嗎？ – Rain 2012-03-06 06:23:18