禁用那些使安全性難以實(shí)施的PHP設(shè)置

1、規(guī)則 1：絕不要信任外部數(shù)據(jù)或輸入關(guān)于 Web 應(yīng)用程序安全性，必須認(rèn)識到的第一件事是不應(yīng)該信任外部數(shù)據(jù)。外部數(shù)據(jù)(outside data) 包括不是由程序員在 PHP 代碼中直接輸入的任何數(shù)據(jù)。在采取措施確保安全之前，來自任何其他來源(比如 GET 變量、表單 POST、數(shù)據(jù)庫、配置文件、會話變量或 cookie)的任何數(shù)據(jù)差不多上不可信任的。例如，下面的數(shù)據(jù)元素能夠被認(rèn)為是安全的，因為它們是在 PHP 中設(shè)置的。清單 1. 安全無暇的代碼以下為引用的內(nèi)容： $myUsername=tmyer;$arrayUsers=array(tmyer,tom,tommy);define(GREETI

2、NG,hellothere.$myUsername);? 然而，下面的數(shù)據(jù)元素差不多上有瑕疵的。清單 2. 不安全、有瑕疵的代碼以下為引用的內(nèi)容： $myUsername=$_POSTusername;/tainted! $arrayUsers=array($myUsername,tom,tommy);/tainted! define(GREETING,hellothere.$myUsername);/tainted! ?什么緣故第一個變量 $myUsername 是有瑕疵的?因為它直接來自表單 POST。用戶能夠在那個輸入域中輸入任何字符串，包括用來清除文件或運(yùn)行往常上傳的文件的惡意命令。您

3、可能會問，“難道不能使用只同意字母 A-Z 的客戶端(Javascrpt)表單檢驗?zāi)_本來幸免這種危險嗎?”是的，這總是一個有好處的步驟，然而正如在后面會看到的，任何人都能夠?qū)⑷魏伪韱蜗螺d 到自己的機(jī)器上，修改它，然后重新提交他們需要的任何內(nèi)容。解決方案專門簡單：必須對 $_POSTusername 運(yùn)行清理代碼。假如不這么做，那么在使用 $myUsername 的任何其他時候(比如在數(shù)組或常量中)，就可能污染這些對象。對用戶輸入進(jìn)行清理的一個簡單方法是，使用正則表達(dá)式來處理它。在那個示例中，只希望同意字母。將字符串限制為特定數(shù)量的字符，或者要求所有字母差不多上小寫的，這可能也是個好主意。清單

4、3. 使用戶輸入變得安全以下為引用的內(nèi)容： $myUsername=cleanInput($_POSTusername);/clean! $arrayUsers=array($myUsername,tom,tommy);/clean! define(GREETING,hellothere.$myUsername);/clean! functioncleanInput($input)$clean=strtolower($input); $clean=preg_replace(/a-z/,$clean); $clean=substr($clean,0,12);return$clean; ?規(guī)則 2

5、：禁用那些使安全性難以實(shí)施的 PHP 設(shè)置差不多明白了不能信任用戶輸入，還應(yīng)該明白不應(yīng)該信任機(jī)器上配置 PHP 的方式。例如，要確保禁用 register_globals。假如啟用了 register_globals，就可能做一些粗心的情況，比如使用 $variable 替換同名的 GET 或 POST 字符串。通過禁用那個設(shè)置，PHP 強(qiáng)迫您在正確的名稱空間中引用正確的變量。要使用來自表單 POST 的變量，應(yīng)該引用 $_POSTvariable。如此就可不能將那個特定變量誤會成 cookie、會話或 GET 變量。 規(guī)則 3：假如不能理解它，就不能愛護(hù)它一些開發(fā)人員使用驚奇的語法，或者將語

6、句組織得專門緊湊，形成簡短然而含義模糊的代碼。這種方式可能效率高，然而假如您不理解代碼正在做什么，那么就無法決定如何愛護(hù)它。例如，您喜愛下面兩段代碼中的哪一段?清單 4. 使代碼容易得到愛護(hù)以下為引用的內(nèi)容： /obfuscatedcode $input=(isset($_POSTusername)?$_POSTusername:); /unobfuscatedcode $input=; if(isset($_POSTusername) $input=$_POSTusername; else $input=; ?在第二個比較清晰的代碼段中，專門容易看出 $input 是有瑕疵的，需要進(jìn)行清理，

7、然后才能安全地處理。規(guī)則 4：“縱深防備” 是新的法寶本教程將用示例來講明如何愛護(hù)在線表單，同時在處理表單的 PHP 代碼中采納必要的措施。同樣，即使使用 PHP regex 來確保 GET 變量完全是數(shù)字的，仍然能夠采取措施確保 SQL 查詢使用轉(zhuǎn)義的用戶輸入?？v深防備不只是一種好思想，它能夠確保您可不能陷入嚴(yán)峻的苦惱。既然差不多討論了差不多規(guī)則，現(xiàn)在就來研究第一種威脅：SQL 注入攻擊。防止 SQL 注入攻擊在 SQL 注入攻擊 中，用戶通過操縱表單或 GET 查詢字符串，將信息添加到數(shù)據(jù)庫查詢中。例如，假設(shè)有一個簡單的登錄數(shù)據(jù)庫。那個數(shù)據(jù)庫中的每個記錄都有一個用戶名字段和一個密碼字段。構(gòu)

8、建一個登錄表單，讓用戶能夠登錄。LoginUsernamePassword那個表單同意用戶輸入的用戶名和密碼，并將用戶輸入提交給名為 verify.php 的文件。在那個文件中，PHP 處理來自登錄表單的數(shù)據(jù)，如下所示：清單 6. 不安全的 PHP 表單處理代碼以下為引用的內(nèi)容： ctr=1) /theyreokaytoentertheapplication! $okay=1; if($okay) $_SESSIONloginokay=true; header(index.php); else header(login.php); ?這段代碼看起來沒問題，對嗎?世界各地成百(甚至成千)的 PH

9、P/MySQL 站點(diǎn)都在使用如此的代碼。它錯在哪里?好，記住 “不能信任用戶輸入”。那個地點(diǎn)沒有對來自用戶的任何信息進(jìn)行轉(zhuǎn)義，因此使應(yīng)用程序容易受到攻擊。具體來講，可能會出現(xiàn)任何類型的 SQL 注入攻擊。例如，假如用戶輸入 foo 作為用戶名，輸入 or 1=1 作為密碼，那么實(shí)際上會將以下字符串傳遞給 PHP，然后將查詢傳遞給 MySQL：以下為引用的內(nèi)容： 那個查詢總是返回計數(shù)值 1，因此 PHP 會同意進(jìn)行訪問。通過在密碼字符串的末尾注入某些惡意 SQL，黑客就能裝扮成合法的用戶。解 決那個問題的方法是，將 PHP 的內(nèi)置 mysql_real_escape_string() 函數(shù)用作任何用戶輸入的包裝器。那個函數(shù)對字符串中的字符進(jìn)行轉(zhuǎn)義，使字符串不可能傳遞撇號等專門字符并讓 MySQL 依照專門字符進(jìn)行操作。清單 7 展示了帶轉(zhuǎn)義處理的代碼。清單 7. 安全的 PHP 表單處理代碼以下為引用的內(nèi)容： ctr=1) /theyreokaytoentertheapplication! $okay=1; if($okay) $_SESSIONloginokay=true; header(index.php); else header(login.php); ?使用 mysql_real_escape_stri