術(shù)語
用戶：訪客。
客戶端：安裝在特定計算機上的特定于Web的軟件。
了解會議
為了了解如何使會話安全，您必須首先了解會話的工作方式。
讓我們看一下這段代碼：
session_start();
調(diào)用后，PHP將查找名為PHPSESSID（默認情況下）的cookie 。如果找不到，它將創(chuàng)建一個：
PHPSESSID=h8p6eoh3djplmnum2f696e4vq3
如果找到它，它將采用值，PHPSESSID然后加載相應(yīng)的會話。該值稱為session_id。
那是客戶唯一會知道的。您添加到會話變量中的任何內(nèi)容都將保留在服務(wù)器上，并且永遠不會傳輸?shù)娇蛻舳?。如果您更改的?nèi)容，則該變量不會更改$_SESSION。在您銷毀它或超時之前，它始終保持不變。因此，嘗試$_SESSION通過散列或其他方式來混淆內(nèi)容是沒有用的，因為客戶端從不接收或發(fā)送該信息。
然后，在新會話的情況下，您將設(shè)置變量：
$_SESSION['user'] = 'someuser';
客戶將永遠不會看到該信息。
問題
當惡意用戶竊取session_id其他用戶的安全性時，可能會出現(xiàn)安全問題。如果沒有某種檢查，他將可以自由地模擬該用戶。我們需要找到一種唯一標識客戶端（而非用戶）的方法。
一種策略（最有效）涉及檢查啟動會話的客戶端的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');
}
該策略的問題在于，如果客戶端使用負載平衡器，或者（在長時間會話中）用戶具有動態(tài)IP，則會觸發(fā)錯誤警報。
另一種策略涉及檢查客戶端的用戶代理：
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');
}
該策略的缺點是，如果客戶端升級瀏覽器或安裝插件（某些插件添加到用戶代理），則用戶代理字符串將更改，并會觸發(fā)錯誤警報。
另一種策略是session_id每5個請求輪換一次。這樣一來，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;
}
您可以根據(jù)需要組合所有這些策略，但同時也要組合不利因素。
不幸的是，沒有解決方案是萬無一失的。如果您session_id受到侵害，那么您就已經(jīng)做好了。以上策略只是權(quán)宜之計。
