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