目標本教程講解如何防御最常見的安全威脅：SQL 注入、操縱 GET 和 POST 變量、緩沖區溢出攻擊、跨站點腳本攻擊、瀏覽器內的數據操縱和遠程表單提交。前提條件本教程是為至少有一年編程經驗的 PHP 開發人員編寫的。您應該了解 PHP 的語法和約定；這里不解釋這些內容。有使用其他語言（比如 Ruby、Python 和 Perl）的經驗的開發人員也能夠從本教程中受益，因為這里討論的許多規則也適用于其他語言和環境。安全性快速簡介Web 應用程序最重要的部分是什么？根據回答問題的人不同，對這個問題的答案可能是五花八門。業務人員需要可靠性和可伸縮性。IT 支持團隊需要健壯的可維護的代碼。最終用戶需要漂亮的用戶界面和執行任務時的高性能。但是，如果回答 “安全性”，那么每個人都會同意這對 Web 應用程序很重要。但是，大多數討論到此就打住了。盡管安全性在項目的檢查表中，但是往往到了項目交付之前才開始考慮解決安全性問題。采用這種方式的 Web 應用程序項目的數量多得驚人。開發人員工作幾個月，只在最后才添加安全特性，從而讓 Web 應用程序能夠向公眾開放。結果往往是一片混亂，甚至需要返工，因為代碼已經經過檢驗、單元測試并集成為更大的框架，之后才在其中添加安全特性。添加安全性之后，主要組件可能會停止工作。安全性的集成使得原本順暢（但不安全）的過程增加額外負擔或步驟。本教程提供一種將安全性集成到 PHP Web 應用程序中的好方法。它討論幾個一般性安全主題，然后深入討論主要的安全漏洞以及如何堵住它們。在學完本教程之后，您會對安全性有更好的理解。主題包括：SQL 注入攻擊操縱 GET 字符串緩沖區溢出攻擊跨站點腳本攻擊（XSS）瀏覽器內的數據操縱遠程表單提交Web 安全性 101在討論實現安全性的細節之前，最好從比較高的角度討論 Web 應用程序安全性。本節介紹安全哲學的一些基本信條，無論正在創建何種 Web 應用程序，都應該牢記這些信條。這些思想的一部分來自 Chris Shiflett（他關于 PHP 安全性的書是無價的寶庫），一些來自 Simson Garfinkel（參見 參考資料），還有一些來自多年積累的知識。規則 1：絕不要信任外部數據或輸入關于 Web 應用程序安全性，必須認識到的第一件事是不應該信任外部數據。外部數據（outside data） 包括不是由程序員在 PHP 代碼中直接輸入的任何數據。在采取措施確保安全之前，來自任何其他來源（比如 GET 變量、表單 POST、數據庫、配置文件、會話變量或 cookie）的任何數據都是不可信任的。例如，下面的數據元素可以被認為是安全的，因為它們是在 PHP 中設置的。清單 1. 安全無暇的代碼 [php]$myUsername = ‘tmyer’;$arrayUsers = array(’tmyer’, ‘tom’, ‘tommy’);define(”GREETING”, ‘hello there’ . $myUsername); [/php]但是，下面的數據元素都是有瑕疵的。清單 2. 不安全、有瑕疵的代碼 [php]$myUsername = $_POST[’username’]; //tainted!$arrayUsers = array($myUsername, ‘tom’, ‘tommy’); //tainted!define(”GREETING”, ‘hello there’ . $myUsername); //tainted! [/php]為什么第一個變量 $myUsername 是有瑕疵的？因為它直接來自表單 POST。用戶可以在這個輸入域中輸入任何字符串，包括用來清除文件或運行以前上傳的文件的惡意命令。您可能會問，“難道不能使用只接受字母 A-Z 的客戶端（JavaScript）表單檢驗腳本來避免這種危險嗎？”是的，這總是一個有好處的步驟，但是正如在后面會看到的，任何人都可以將任何表單下載到自己的機器上，修改它，然后重新提交他們需要的任何內容。解決方案很簡單：必須對 $_POST[’username’] 運行清理代碼。如果不這么做，那么在使用 $myUsername 的任何其他時候（比如在數組或常量中），就可能污染這些對象。對用戶輸入進行清理的一個簡單方法是，使用正則表達式來處理它。在這個示例中，只希望接受字母。將字符串限制為特定數量的字符，或者要求所有字母都是小寫的，這可能也是個好主意。清單 3. 使用戶輸入變得安全 [php]$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;}[/php]規則 2：禁用那些使安全性難以實施的 PHP 設置已經知道了不能信任用戶輸入，還應該知道不應該信任機器上配置 PHP 的方式。例如，要確保禁用 register_globals。如果啟用了 register_globals，就可能做一些粗心的事情，比如使用 $variable 替換同名的 GET 或 POST 字符串。通過禁用這個設置，PHP 強迫您在正確的名稱空間中引用正確的變量。要使用來自表單 POST 的變量，應該引用 $_POST[’variable’]。這樣就不會將這個特定變量誤會成 cookie、會話或 GET 變量。要檢查的第二個設置是錯誤報告級別。在開發期間，希望獲得盡可能多的錯誤報告，但是在交付項目時，希望將錯誤記錄到日志文件中，而不是顯示在屏幕上。為什么呢？因為惡意的黑客會使用錯誤報告信息（比如 SQL 錯誤）來猜測應用程序正在做什么。這種偵察可以幫助黑客突破應用程序。為了堵住這個漏洞，需要編輯 php.ini 文件，為 error_log 條目提供合適的目的地，并將 display_errors 設置為 Off。規則 3：如果不能理解它，就不能保護它一些開發人員使用奇怪的語法，或者將語句組織得很緊湊，形成簡短但是含義模糊的代碼。這種方式可能效率高，但是如果您不理解代碼正在做什么，那么就無法決定如何保護它。例如，您喜歡下面兩段代碼中的哪一段？清單 4. 使代碼容易得到保護 [php]//obfuscated code$input = (isset($_POST[’username’]) ? $_POST[’username’]:”);//unobfuscated code$input = ”;if (isset($_POST[’username’])){$input = $_POST[’username’];}else{$input = ”;}[/php]在第二個比較清晰的代碼段中，很容易看出 $input 是有瑕疵的，需要進行清理，然后才能安全地處理。規則 4：“縱深防御” 是新的法寶本教程將用示例來說明如何保護在線表單，同時在處理表單的 PHP 代碼中采用必要的措施。同樣，即使使用 PHP regex 來確保 GET 變量完全是數字的，仍然可以采取措施確保 SQL 查詢使用轉義的用戶輸入。縱深防御不只是一種好思想，它可以確保您不會陷入嚴重的麻煩。既然已經討論了基本規則，現在就來研究第一種威脅：SQL 注入攻擊。防止 SQL 注入攻擊在 SQL 注入攻擊 中，用戶通過操縱表單或 GET 查詢字符串，將信息添加到數據庫查詢中。例如，假設有一個簡單的登錄數據庫。這個數據庫中的每個記錄都有一個用戶名字段和一個密碼字段。構建一個登錄表單，讓用戶能夠登錄。清單 5. 簡單的登錄表單 [php]Login

Username

Password

[/php] 這個表單接受用戶輸入的用戶名和密碼，并將用戶輸入提交給名為 verify.php 的文件。在這個文件中，PHP 處理來自登錄表單的數據，如下所示：清單 6. 不安全的 PHP 表單處理代碼 [php] $okay = 0;$username = $_POST[’user’];$pw = $_POST[’pw’];$sql = “select count(*) as ctr from users whereusername=’”.$username.”‘ and password=’”. $pw.”‘ limit 1″;$result = mysql_query($sql);while ($data = mysql_fetch_object($result)){if ($data->ctr == 1){ //they’re okay to enter the application! $okay = 1;}}if ($okay){$_SESSION[’loginokay’] = true;header(”index.php”);}else{header(”login.php”);}?> [/php]這段代碼看起來沒問題，對嗎？世界各地成百（甚至成千）的 PHP/MySQL 站點都在使用這樣的代碼。它錯在哪里？好，記住 “不能信任用戶輸入”。這里沒有對來自用戶的任何信息進行轉義，因此使應用程序容易受到攻擊。具體來說，可能會出現任何類型的 SQL 注入攻擊。例如，如果用戶輸入 foo 作為用戶名，輸入 ‘ or ‘1′=’1 作為密碼，那么實際上會將以下字符串傳遞給 PHP，然后將查詢傳遞給 MySQL：$sql = “select count(*) as ctr from users where username=’foo’ and password=” or ‘1′=’1′ limit 1″; 這個查詢總是返回計數值 1，因此 PHP 會允許進行訪問。通過在密碼字符串的末尾注入某些惡意 SQL，黑客就能裝扮成合法的用戶。解決這個問題的辦法是，將 PHP 的內置 mysql_real_escape_string() 函數用作任何用戶輸入的包裝器。這個函數對字符串中的字符進行轉義，使字符串不可能傳遞撇號等特殊字符并讓 MySQL 根據特殊字符進行操作。清單 7 展示了帶轉義處理的代碼。清單 7. 安全的 PHP 表單處理代碼 [php] $okay = 0;$username = $_POST[’user’];$pw = $_POST[’pw’];$sql = “select count(*) as ctr from users where username=’”.mysql_real_escape_string($username).”‘ and password=’”. mysql_real_escape_string($pw).”‘ limit 1″; $result = mysql_query($sql);while ($data = mysql_fetch_object($result)){if ($data->ctr == 1){ //they’re okay to enter the application! $okay = 1;}}if ($okay){$_SESSION[’loginokay’] = true;header(”index.php”);}else{header(”login.php”);}?>[/php]使用 mysql_real_escape_string() 作為用戶輸入的包裝器，就可以避免用戶輸入中的任何惡意 SQL 注入。如果用戶嘗試通過 SQL 注入傳遞畸形的密碼，那么會將以下查詢傳遞給數據庫：select count(*) as ctr from users where username=’foo’ and password=’’ or ’1’=’1′ limit 1″ 數據庫中沒有任何東西與這樣的密碼匹配。僅僅采用一個簡單的步驟，就堵住了 Web 應用程序中的一個大漏洞。這里得出的經驗是，總是應該對 SQL 查詢的用戶輸入進行轉義。但是，還有幾個安全漏洞需要堵住。下一項是操縱 GET 變量。防止用戶操縱 變量在前一節中，防止了用戶使用畸形的密碼進行登錄。如果您很聰明，應該應用您學到的方法，確保對 SQL 語句的所有用戶輸入進行轉義。但是，用戶現在已經安全地登錄了。用戶擁有有效的密碼，并不意味著他將按照規則行事 —— 他有很多機會能夠造成損害。例如，應用程序可能允許用戶查看特殊的內容。所有鏈接指向 template.php?pid=33 或 template.php?pid=321 這樣的位置。URL 中問號后面的部分稱為查詢字符串。因為查詢字符串直接放在 URL 中，所以也稱為 GET 查詢字符串。在 PHP 中，如果禁用了 register_globals，那么可以用 $_GET[’pid’] 訪問這個字符串。在 template.php 頁面中，可能會執行與清單 8 相似的操作。清單 8. 示例 template.php [php] $pid = $_GET[’pid’];//we create an object of a fictional class Page$obj = new Page;$content = $obj->fetchPage($pid);//and now we have a bunch of PHP that displays the page//……//……?> [/php]這里有什么錯嗎？首先，這里隱含地相信來自瀏覽器的 GET 變量 pid 是安全的。這會怎么樣呢？大多數用戶沒那么聰明，無法構造出語義攻擊。但是，如果他們注意到瀏覽器的 URL 位置域中的 pid=33，就可能開始搗亂。如果他們輸入另一個數字，那么可能沒問題；但是如果輸入別的東西，比如輸入 SQL 命令或某個文件的名稱（比如 /etc/passwd），或者搞別的惡作劇，比如輸入長達 3,000 個字符的數值，那么會發生什么呢？在這種情況下，要記住基本規則，不要信任用戶輸入。應用程序開發人員知道 template.php 接受的個人標識符（PID）應該是數字，所以可以使用 PHP 的 is_numeric() 函數確保不接受非數字的 PID，如下所示：清單 9. 使用 is_numeric() 來限制 GET 變量 [php] $pid = $_GET[’pid’];if (is_numeric($pid)){//we create an object of a fictional class Page$obj = new Page;$content = $obj->fetchPage($pid);//and now we have a bunch of PHP that displays the page //……//……}else{//didn’t pass the is_numeric() test, do something else!}?> [/php]這個方法似乎是有效的，但是以下這些輸入都能夠輕松地通過 is_numeric() 的檢查：100 （有效）100.1 （不應該有小數位）+0123.45e6 （科學計數法 —— 不好）0xff33669f （十六進制 —— 危險！危險！）那么，有安全意識的 PHP 開發人員應該怎么做呢？多年的經驗表明，最好的做法是使用正則表達式來確保整個 GET 變量由數字組成，如下所示：清單 10. 使用正則表達式限制 GET 變量 [php] $pid = $_GET[’pid’];if (strlen($pid)){if (!ereg(”^[0-9]+$”,$pid)){ //do something appropriate, like maybe logging them out or sending them back to home page}}else{//empty $pid, so send them back to the home page}//we create an object of a fictional class Page, which is now//moderately protected from evil user input$obj = new Page;$content = $obj->fetchPage($pid);//and now we have a bunch of PHP that displays the page //……//……?>[/php]需要做的只是使用 strlen() 檢查變量的長度是否非零；如果是，就使用一個全數字正則表達式來確保數據元素是有效的。如果 PID 包含字母、斜線、點號或任何與十六進制相似的內容，那么這個例程捕獲它并將頁面從用戶活動中屏蔽。如果看一下 Page 類幕后的情況，就會看到有安全意識的 PHP 開發人員已經對用戶輸入 $pid 進行了轉義，從而保護了 fetchPage() 方法，如下所示：清單 11. 對 fetchPage() 方法進行轉義 [php] class Page{ function fetchPage($pid){ $sql = “select pid,title,desc,kw,content, status from page where pid=’ ”.mysql_real_escape_string($pid).”‘”; //etc, etc….}}?> [/php]您可能會問，“既然已經確保 PID 是數字，那么為什么還要進行轉義？” 因為不知道在多少不同的上下文和情況中會使用 fetchPage() 方法。必須在調用這個方法的所有地方進行保護，而方法中的轉義體現了縱深防御的意義。如果用戶嘗試輸入非常長的數值，比如長達 1000 個字符，試圖發起緩沖區溢出攻擊，那么會發生什么呢？下一節更詳細地討論這個問題，但是目前可以添加另一個檢查，確保輸入的 PID 具有正確的長度。您知道數據庫的 pid 字段的最大長度是 5 位，所以可以添加下面的檢查。清單 12. 使用正則表達式和長度檢查來限制 GET 變量 [php] $pid = $_GET[’pid’];if (strlen($pid)){if (!ereg(”^[0-9]+$”,$pid) && strlen($pid) > 5){ //do something appropriate, like maybe logging them out or sending them back to home page}}else{//empty $pid, so send them back to the home page}//we create an object of a fictional class Page, which is now//even more protected from evil user input$obj = new Page;$content = $obj->fetchPage($pid);//and now we have a bunch of PHP that displays the page //……//……?> [/php]現在，任何人都無法在數據庫應用程序中塞進一個 5,000 位的數值 —— 至少在涉及 GET 字符串的地方不會有這種情況。想像一下黑客在試圖突破您的應用程序而遭到挫折時咬牙切齒的樣子吧！而且因為關閉了錯誤報告，黑客更難進行偵察。緩沖區溢出攻擊緩沖區溢出攻擊 試圖使 PHP 應用程序中（或者更精確地說，在 Apache 或底層操作系統中）的內存分配緩沖區發生溢出。請記住，您可能是使用 PHP 這樣的高級語言來編寫 Web 應用程序，但是最終還是要調用 C（在 Apache 的情況下）。與大多數低級語言一樣，C 對于內存分配有嚴格的規則。緩沖區溢出攻擊向緩沖區發送大量數據，使部分數據溢出到相鄰的內存緩沖區，從而破壞緩沖區或者重寫邏輯。這樣就能夠造成拒絕服務、破壞數據或者在遠程服務器上執行惡意代碼。防止緩沖區溢出攻擊的惟一方法是檢查所有用戶輸入的長度。例如，如果有一個表單元素要求輸入用戶的名字，那么在這個域上添加值為 40 的 maxlength 屬性，并在后端使用 substr() 進行檢查。清單 13 給出表單和 PHP 代碼的簡短示例。清單 13. 檢查用戶輸入的長度 [php] if ($_POST[’submit’] == “go”){$name = substr($_POST[’name’],0,40);//continue processing….}?>