關於會話，需要關注的主要問題是會話標識的保密性問題。如果它是保密的，就不會存在會話劫持的風險了。通過乙個合法的會話標識，乙個攻擊者可以非常成功地冒充成為你的某乙個使用者。
乙個攻擊者可以通過三種方法來取得合法的會話標識：
猜測捕獲
固定php生成的是隨機性很強的會話標識，所以被猜測的風險是不存在的。常見的是通過捕獲網路通訊資料以得到會話標識。為了避免會話標識**獲的風險，可以使用ssl，同時還要對瀏覽器漏洞及時修補。
要記住瀏覽器會根據請求中的set-cookie頭部中的要求對之後所有的請求中都包含乙個相應的cookie頭部。最常見的是，會話標識會無謂的在對一些嵌入資源如的請求中被暴露。例如，請求乙個包含10個的網頁時，瀏覽器會發出11個帶有會話標識的請求，但只有乙個是有必要帶有標識的。為了防止這種無謂的暴露，你可以考慮把所有的嵌入資源放在有另外乙個網域名稱的伺服器上。
會話固定是一種誘騙受害者使用攻擊者指定的會話標識的攻擊手段。這是攻擊者獲取合法會話標識的最簡單的方法。在這個最簡單的例子中，使用了乙個鏈結進行會話固定攻擊：
click here
另外乙個方法是使用乙個協議級別的轉向語句：
[php]view plain
copy
<?php
header('location: =
""target=
"_blank"
>');
?>
這也可以通過refresh頭部來進行，產生該頭部的方法是通過真正的http頭部或meta標籤的http-equiv屬性指定。攻擊者的目標是讓使用者訪問包含有攻擊者指定的會話標識的url。這是乙個基本的攻擊的第一步，完整的攻擊過程見圖：
使用攻擊者指定的會話標識進行的會話固定攻擊
如果成功了，攻擊者就能繞過抓取或猜測合法會話標識的需要，這就使發起更多和更危險的攻擊成為可能。為了更好地使你理解這一步驟，最好的辦法是你自己嘗試一下。首先建立乙個名為fixation.php的指令碼：
[php]view plain
copy
<?php
session_start();
$_session
['username'
] =
'chris'
; ?>
確認你沒有儲存著任何當前伺服器的cookies，或通過清除所有的cookies以確保這一點。通過包含phpsessid的url訪問fixation.php：
它建立了乙個值為chris的會話變數username。在檢查會話儲存區後發現1234成為了該資料的會話標識：
[php]view plain
copy
$ cat /tmp/sess_1234
username|s:5:"chris"
;
建立第二段指令碼test.php，它在$_session['username']存在的情況下即輸入出該值：
[php]view plain
copy
<?php
session_start();
if(isset(
$_session
['username'
]))
?>
在另外一台計算機上或者在另乙個瀏覽器中訪問下面的url，同時該url指定了相同的會話標識：
這使你可以在另一台計算機上或瀏覽器中（模仿攻擊者所在位置）恢復前面在fixation.php中建立的會話。這樣，你就作為乙個攻擊者成功地劫持了乙個會話。
很明顯，我們不希望這種情況發生。因為通過上面的方法，攻擊者會提供乙個到你的應用的鏈結，只要通過這個鏈結對你的**進行訪問的使用者都會使用攻擊者所指定的會話標識。產生這個問題的乙個原因是會話是由url中的會話標識所建立的。當沒有指定會話標識時，php就會自動產生乙個。這就為攻擊者大開了方便之門。幸運的是，我們以可以使用session_regenerate_id( )函式來防止這種情況的發生。
[php]view plain
copy
<?php
session_start();
if(!isset(
$_session
['initiated'
]))
?>
這就保證了在會話初始化時能有乙個全新的會話標識。可是，這並不是防止會話固定攻擊的有效解決方案。攻擊者能簡單地通過訪問你的**，確定php給出的會話標識，並且在會話固定攻擊中使用該會話標識。
這確實使攻擊者沒有機會去指定乙個簡單的會話標識，如1234，但攻擊者依然可以通過檢查cookie或url（依賴於標識的傳遞方式）得到php指定的會話標識。會話的這個弱點，同時它可以幫助你理解該問題涉及的範圍。會話固定只是乙個基礎，攻擊的目的是要取得乙個能用來劫持會話的標識。這通常用於這樣的乙個系統，在這個系統中，攻擊者能合法取得較低的許可權(該許可權級別只要能登入即可)，這樣劫持乙個具有較高許可權的會話是非常有用的。
如果會話標識在許可權等級有改變時重新生成，就可以在事實上避開會話固定的風險：
[php]view plain
copy
<?php
$_session
['logged_in'
] = false;
if(check_login())
?>
通過首先初始化會話進行會話固定攻擊
我不推薦在每一頁上重新生成會話標識。雖然這看起來確實是乙個安全的方法。但與在許可權等級變化時重新生成會話標識相比，並沒有提供更多的保護手段。更重要的是，相反地它還會對你的合法使用者產生影響，特別是會話標識通過url傳遞時尤甚。使用者可能會使用瀏覽器的訪問歷史機制去訪問以前訪問的頁面，這樣該頁上的鏈結就會指向乙個不再存在的會話標識。
如果你只在許可權等級變化時重新生成會話標識，同樣的情況也有可以發生，但是使用者在訪問許可權變更前的頁面時，不會因為會話丟失而奇怪，同時，這種情況也不常見。
PHP安全程式設計之session固定獲取合法會話
關於會話，需要關注的主要問題是會話標識的保密性問題。如果它是保密的，就不會存在會話劫持的風險了。通過乙個合法的會話標識，乙個攻擊者可以非常成功地冒充成為你的某乙個使用者。乙個攻擊者可以通過三種方法來取得合法的會話標識 php生成的是隨機性很強的會話標識，所以被猜測的風險是不存在的。常見的是通過捕獲網...
PHP安全程式設計
一 外部策略 1.處理使用者的提交的資料 get post request cookie argv php stdin php input file get contents 遠端的資料庫資訊 遠端api 來自客戶端的資料 以上的資料來源都很可能被作為資料來源插入到你的php指令碼中從而造成 xss...
PHP安全程式設計之PHP的安全模式
php的safe mode選項的目的是為了解決本小節前後所述的某些問題。但是，在php層面上去解決這類問題從架構上來看是不正確的，正如php手冊所述 當安全模式生效時，php會對正在執行的指令碼所讀取 或所操作 檔案的屬主進行檢查，以保證與該指令碼的屬主是相同的。雖然這樣確實可以防範本章中的很多例子...