確保PHP安全 不能違反的四條安全規(guī)則

規(guī)則 1：絕不要信任外部數(shù)據(jù)或輸入

關(guān)于 Web 應(yīng)用程序安全性，必須認識到的第一件事是不應(yīng)該信任外部數(shù)據(jù)。外部數(shù)據(jù)（outside data） 包括不是由程序員在 PHP 代碼中直接輸入的任何數(shù)據(jù)。在采取措施確保安全之前，來自任何其他來源（比如 GET 變量、表單 POST、數(shù)據(jù)庫、配置文件、會話變量或 cookie）的任何數(shù)據(jù)都是不可信任的。

例如，下面的數(shù)據(jù)元素可以被認為是安全的，因為它們是在 PHP 中設(shè)置的。

清單 1. 安全無暇的代碼

以下為引用的內(nèi)容：

$myUsername = 'tmyer';
            
$arrayUsers = array('tmyer', 'tom', 'tommy');
            
define("GREETING", 'hello there' . $myUsername);
            
?> 
            

但是，下面的數(shù)據(jù)元素都是有瑕疵的。

清單 2. 不安全、有瑕疵的代碼

以下為引用的內(nèi)容：

$myUsername = $_POST['username']; //tainted!
            
$arrayUsers = array($myUsername, 'tom', 'tommy'); //tainted!
            
define("GREETING", 'hello there' . $myUsername); //tainted!
            
?> 
            

為 什么第一個變量 $myUsername 是有瑕疵的？因為它直接來自表單 POST。用戶可以在這個輸入域中輸入任何字符串，包括用來清除文件或運行以前上傳的文件的惡意命令。您可能會問，“難道不能使用只接受字母 A-Z 的客戶端（Javascrīpt）表單檢驗?zāi)_本來避免這種危險嗎？”是的，這總是一個有好處的步驟，但是正如在后面會看到的，任何人都可以將任何表單下載 到自己的機器上，修改它，然后重新提交他們需要的任何內(nèi)容。

解決方案很簡單：必須對 $_POST['username'] 運行清理代碼。如果不這么做，那么在使用 $myUsername 的任何其他時候（比如在數(shù)組或常量中），就可能污染這些對象。

對用戶輸入進行清理的一個簡單方法是，使用正則表達式來處理它。在這個示例中，只希望接受字母。將字符串限制為特定數(shù)量的字符，或者要求所有字母都是小寫的，這可能也是個好主意。

清單 3. 使用戶輸入變得安全

以下為引用的內(nèi)容：

$myUsername = cleanInput($_POST['username']); //clean!
            
$arrayUsers = array($myUsername, 'tom', 'tommy'); //clean!
            
define("GREETING", 'hello there' . $myUsername); //clean!
            
function cleanInput($input){   $clean = strtolower($input);    
            
$clean = preg_replace("/[^a-z]/", "", $clean);    
            
$clean = substr($clean,0,12);
            
return $clean;
            
}
            
?> 
            

規(guī)則 2：禁用那些使安全性難以實施的 PHP 設(shè)置

已經(jīng)知道了不能信任用戶輸入，還應(yīng)該知道不應(yīng)該信任機器上配置 PHP 的方式。例如，要確保禁用 register_globals。如果啟用了 register_globals，就可能做一些粗心的事情，比如使用 $variable 替換同名的 GET 或 POST 字符串。通過禁用這個設(shè)置，PHP 強迫您在正確的名稱空間中引用正確的變量。要使用來自表單 POST 的變量，應(yīng)該引用 $_POST['variable']。這樣就不會將這個特定變量誤會成 cookie、會話或 GET 變量。

規(guī)則 3：如果不能理解它，就不能保護它

一些開發(fā)人員使用奇怪的語法，或者將語句組織得很緊湊，形成簡短但是含義模糊的代碼。這種方式可能效率高，但是如果您不理解代碼正在做什么，那么就無法決定如何保護它。

例如，您喜歡下面兩段代碼中的哪一段？

清單 4. 使代碼容易得到保護

以下為引用的內(nèi)容：

//obfuscated code
            
$input = (isset($_POST['username']) ? $_POST['username']:'');
            
//unobfuscated code
            
$input = '';
            
if (isset($_POST['username'])){    
            
$input = $_POST['username'];
            
}else{ 
            
$input = '';
            
}
            
?> 
            

在第二個比較清晰的代碼段中，很容易看出 $input 是有瑕疵的，需要進行清理，然后才能安全地處理。

規(guī)則 4：“縱深防御” 是新的法寶

本教程將用示例來說明如何保護在線表單，同時在處理表單的 PHP 代碼中采用必要的措施。同樣，即使使用 PHP regex 來確保 GET 變量完全是數(shù)字的，仍然可以采取措施確保 SQL 查詢使用轉(zhuǎn)義的用戶輸入。

縱深防御不只是一種好思想，它可以確保您不會陷入嚴(yán)重的麻煩。

既然已經(jīng)討論了基本規(guī)則，現(xiàn)在就來研究第一種威脅：SQL 注入攻擊。

防止 SQL 注入攻擊

在 SQL 注入攻擊 中，用戶通過操縱表單或 GET 查詢字符串，將信息添加到數(shù)據(jù)庫查詢中。例如，假設(shè)有一個簡單的登錄數(shù)據(jù)庫。這個數(shù)據(jù)庫中的每個記錄都有一個用戶名字段和一個密碼字段。構(gòu)建一個登錄表單，讓用戶能夠登錄。

$myUsername = 'tmyer';

$arrayUsers = array('tmyer', 'tom', 'tommy');

define("GREETING", 'hello there' . $myUsername);

?>