一、 建立一個安全抽象層
我們並不建議你手工地把前面介紹的技術應用於每一個使用者輸入的執行個體中,而是強烈推薦你為此建立一個抽象層。一個簡單的抽象是把你的校正方案加入到一個函數中,並且針對使用者輸入的每一項調用這個函數。當然,我們還可以建立一種更複雜的更高一級的抽象-把一個安全的查詢封裝到一個類中,從而應用於整個應用程式。在網上已經存在許多這種現成的免費的類;在本篇中,我們正要討論其中的一些。
進行這種抽象至少存在三個優點(而且每一個都會改進安全層級):
1. 本地化代碼。
2. 使查詢的構造更快且更為可靠-因為這可以把部分工作交由抽象代碼來實現。
3. 當基於安全特徵進行構建並且恰當使用時,這將會有效地防止我們前面所討論的各種各樣的注入式攻擊。
二、 改進現有的應用程式
如果你想改進一個現有的應用程式,則使用一個簡單的抽象層是最適當的。一個能夠簡單地"清理"你所收集的任何使用者輸入內容的函數可能看起來如下所示:
function safe( $string ) {
return "'" . MySQL_real_escape_string( $string ) . "'"
}
【注意】我們已經構建了相應於值要求的單引號以及mysql_real_escape_string()函數。接下來,就可以使用這個函數來構造一個$query變數,如下所示:
$variety = safe( $_POST['variety'] );
$query = " SELECT * FROM wines WHERE variety=" . $variety;
現在,你的使用者試圖進行一個注入式攻擊-通過輸入下列內容作為變數$variety的值:
lagrein' or 1=1;
注意,如果不進行上面的"清理",則最後的查詢將如下所示(這將導致無法預料的結果):
SELECT * FROM wines WHERE variety = 'lagrein' or 1=1;'
然而現在,既然使用者的輸入已經被清理,那麼查詢語句就成為下面這樣一種無危害的形式:
SELECT * FROM wines WHERE variety = 'lagrein\' or 1=1\;'
既然資料庫中不存在與指定的值相應的variety域(這正是惡意使用者所輸入的內容-lagrein' or 1=1;),那麼,這個查詢將不能返回任何結果,並且注入將會失敗。
三、 保護一個新的應用程式
如果你正在建立一個新的應用程式,那麼,你可以從頭開始建立一個安全抽象層。如今,php 5新改進的對於MySQL的支援(這主要體現在新的mysqli擴充中)為這種安全特徵提供了強有力的支援(既有過程性的,也有物件導向特徵的)。你可以從網站http://php.net/mysqli上擷取有關mysqli的資訊。注意,只有當你使用--with-mysqli=path/to/mysql_config選項編譯PHP時,這種mysqli支援才可用。下面是該代碼的一個過程性版本,用於保護一個基於mysqli的查詢:
<?php
//檢索使用者的輸入
$animalName = $_POST['animalName'];
//串連到資料庫
$connect = mysqli_connect( 'localhost', 'username', 'passWord', 'database' );
if ( !$connect ) exit( 'connection failed: ' . mysqli_connect_error() );
//建立一個查詢語句源
$stmt = mysqli_PRepare( $connect,"SELECT intelligence FROM animals WHERE name = ?" );
if ( $stmt ) {
//把替代綁定到語句上
mysqli_stmt_bind_param( $stmt, "s", $animalName );
//執行該語句
mysqli_stmt_execute( $stmt );
//檢索結果...
mysqli_stmt_bind_result( $stmt, $intelligence );
// ...並顯示它
if ( mysqli_stmt_fetch( $stmt ) ) {
print "A $animalName has $intelligence intelligence.\n";
} else {
print 'Sorry, no records found.';
}
//清除語句源
mysqli_stmt_close( $stmt );
}
mysqli_close( $connect );
?>
該mysqli擴充提供了一組函數用於構造和執行查詢。而且,它也非常準確地提供了前面使用我們自己的safe()函數所實現的功能。
在上面的片斷中,首先收集使用者提交的輸入內容並建立資料庫連接。然後,使用mysqli_prepare()函數建立一個查詢語句源-在此命名為$stmt以反映使用它的函數的名稱。這個函數使用了兩個參數:串連資源和一個字串(每當你使用擴充插入一個值時,"?"標記被插入到其中)。在本例中,你僅有一個這樣的值-動物的名字。
注意,在一個SELECT語句中,放置"?"標記的唯一的有效位置是在值比較部分。這正是為什麼你不需要指定使用哪個變數的原因(除了在mysqli_stmt_bind_param()函數中之外)。在此,你還需要指定它的類型-在本例中,"s"代表字串。其它可能的類型有:"I"代表整數,"d"代表雙精確度數(或浮點數),而"b"代表二進位字串。
函數mysqli_stmt_execute(),mysqli_stmt_bind_result()和mysqli_stmt_fetch()負責執行查詢並檢索結果。如果存在檢索結果,則顯示它們;如果不存在結果,則顯示一條無害的訊息。最後,你需要關閉$stmt資源以及資料庫連接-從記憶體中對它們加以釋放。
假定一個合法的使用者輸入了字串"lemming",那麼這個常式將(假定是資料庫中適當的資料)輸出訊息"A lemming has very low intelligence."。假定存在一個嘗試性注入-例如"lemming' or 1=1;",那麼這個常式將列印(無害)訊息"Sorry, no records found."。
此外,mysqli擴充還提供了一個物件導向版本的相同的常式。下面,我們想說明這種版本的使用方法。
<?php
$animalName = $_POST['animalName'];
$mysqli = new mysqli( 'localhost', 'username', 'password', 'database');
if ( !$mysqli ) exit( 'connection failed: ' . mysqli_connect_error() );
$stmt = $mysqli->prepare( "SELECT intelligence
FROM animals WHERE name = ?" );
if ( $stmt ) {
$stmt->bind_param( "s", $animalName );
$stmt->execute();
$stmt->bind_result( $intelligence );
if ( $stmt->fetch() ) {
print "A $animalName has $intelligence intelligence.\n";
} else {
print 'Sorry, no records found.';
}
$stmt->close();
}
$mysqli->close();
?>
實際上,這部分代碼是前面描述代碼的複製-它使用了一種物件導向的文法和組織方法,而不是嚴格的過程式代碼。
四、 更進階的抽象
如果你使用外部庫PearDB,那麼,你可以對應用程式的安全保護模組進行全面的抽象。
另一方面,使用這個庫存在一個突出的缺點:你只能受限於某些人的思想,而且代碼管理方面也添加了大量的工作。為此,在決定是否使用它們之前,你需要進行仔細地斟酌。如果你決定這樣做,那麼,你至少確保它們能夠真正協助你"清理"你的使用者輸入的內容。
五、 測試你的注入式保護能力
正如我們在前面所討論的,確保你的指令碼安全的一個重要的部分是對它們進行測試。為此,最好的辦法是你自己建立SQL代碼注入測試。
在此,我們提供了一個這種測試的樣本。在本例中,我們測試對一個SELECT語句的注入式攻擊。
<?php
//被測試的保護函數
function safe( $string ) {
return "'" . mysql_real_escape_string( $string ) . "'"
}
//串連到資料庫
///////////////////////
//試圖進行注入
///////////////////////
$exploit = "lemming' AND 1=1;";
//進行清理
$safe = safe( $exploit );
$query = "SELECT * FROM animals WHERE name = $safe";
$result = mysql_query( $query );
//測試是否保護是足夠的
if ( $result && mysql_num_rows( $result ) == 1 ) {
exitt "Protection succeeded:\n
exploit $exploit was neutralized.";
}
else {
exit( "Protection failed:\n
exploit $exploit was able to retrieve all rows." );
}
?>
如果你想建立這樣的一個測試集,並實驗基於不同的SQL命令的各種不同的注入,那麼,你將會很快地探測出你的保護原則中的任何漏洞。一旦糾正這些問題,那麼,你就可以很有把握-你已經建立起真正的注入式攻擊保護機制。
六、 小結
在本系列文章一開始,我們通過一個SQL注入討論分析了對你的指令碼的特定威脅-由不恰當的使用者輸入所致。之後,我們描述了SQL注入的工作原理並精確地分析了PHP是怎樣易於被注入的。然後,我們提供了一個實際中的注入樣本。之後,我們推薦一系列措施來使試圖的注入攻擊變為無害的-這將分別通過確保使所有提交的值以引號封閉,通過檢查使用者提交值的類型,以及通過過濾掉你的使用者輸入的潛在危險的字元等方法來實現的。最後,我們推薦,你最好對你的校正常式進行抽象,並針對更改一個現有應用程式提供了指令碼樣本。然後,我們討論了第三方抽象方案的優缺點。
全文完