在本系列文章中，我們將全面探討如何在PHP開發環境中全面阻止SQL注入式攻擊，并給出一個具體的開發示例。

一、 引言

PHP是一種力量強大但相當容易學習的服務器端腳本語言，即使是經驗不多的程序員也能夠使用它來創建復雜的動態的web站點。然而，它在實現因特網服務的秘密和安全方面卻常常存在許多困難。在本系列文章中，我們將向讀者介紹進行web開發所必需的安全背景以及PHP特定的知識和代碼-你可以借以保護你自己的web應用程序的安全性和一致性。首先，我們簡單地回顧一下服務器安全問題-展示你如何存取一個共享宿主環境下的私人信息，使開發者脫離開生產服務器，維持最新的軟件，提供加密的頻道，并且控制對你的系統的存取。

然后，我們討論PHP腳本實現中的普遍存在的脆弱性。我們將解釋如何保護你的腳本免于SQL注入，防止跨站點腳本化和遠程執行，并且阻止對臨時文件及會話的'劫持'。

在最后一篇中，我們將實現一個安全的Web應用程序。你將學習如何驗證用戶身份，授權并跟蹤應用程序使用，避免數據損失，安全地執行高風險性的系統命令，并能夠安全地使用web服務。無論你是否有足夠的PHP安全開發經驗，本系列文章都會提供豐富的信息來幫助你構建更為安全的在線應用程序。

二、 什么是SQL注入

如果你打算永遠不使用某些數據的話，那么把它們存儲于一個數據庫是毫無意義的;因為數據庫的設計目的是為了方便地存取和操作數據庫中的數據。但是，如果只是簡單地這樣做則有可能會導致潛在的災難。這種情況并不主要是因為你自己可能偶然刪除數據庫中的一切;而是因為，當你試圖完成某項'無辜'的任務時，你有可能被某些人所'劫持'-使用他自己的破壞性數據來取代你自己的數據。我們稱這種取代為'注入'。

其實，每當你要求用戶輸入構造一個數據庫查詢，你是在允許該用戶參與構建一個存取數據庫服務器的命令。一位友好的用戶可能對實現這樣的操作感覺很滿意;然而，一位惡意的用戶將會試圖發現一種方法來扭曲該命令，從而導致該被的扭曲命令刪除數據，甚至做出更為危險的事情。作為一個程序員，你的任務是尋找一種方法來避免這樣的惡意攻擊。

三、 SQL注入工作原理

構造一個數據庫查詢是一個非常直接的過程。典型地，它會遵循如下思路來實現。僅為說明問題，我們將假定你有一個葡萄酒數據庫表格'wines'，其中有一個字段為'variety'(即葡萄酒類型)：

1. 提供一個表單-允許用戶提交某些要搜索的內容。讓我們假定用戶選擇搜索類型為'lagrein'的葡萄酒。

2. 檢索該用戶的搜索術語，并且保存它-通過把它賦給一個如下所示的變量來實現：

$variety = $_POST['variety'];

因此，變量$variety的值現在為：

lagrein

3. 然后，使用該變量在WHERE子句中構造一個數據庫查詢：

$query = 'SELECT * FROM wines WHERE variety='$variety'';

所以，變量$query的值現在如下所示：

SELECT * FROM wines WHERE variety='lagrein'

4. 把該查詢提交給MySQL服務器。

5. MySQL返回wines表格中的所有記錄-其中，字段variety的值為'lagrein'。

到目前為止，這應該是一個你所熟悉的而且是非常輕松的過程。遺憾的是，有時我們所熟悉并感到舒適的過程卻容易導致我們產生自滿情緒。現在，讓我們再重新分析一下剛才構建的查詢。

1. 你創建的這個查詢的固定部分以一個單引號結束，你將使用它來描述變量值的開始：

$query = ' SELECT * FROM wines WHERE variety = '';

2. 使用原有的固定不變的部分與包含用戶提交的變量的值：

$query .= $variety;

3. 然后，你使用另一個單引號來連接此結果-描述該變量值的結束：

$ query .= ''';

于是，$query的值如下所示：

SELECT * FROM wines WHERE variety = 'lagrein'

這個構造的成功依賴用戶的輸入。在本文示例中，你正在使用單個單詞(也可能是一組單詞)來指明一種葡萄酒類型。因此，該查詢的構建是無任何問題的，并且結果也會是你所期望的-一個葡萄酒類型為'lagrein'的葡萄酒列表。現在，讓我們想象，既然你的用戶不是輸入一個簡單的類型為'lagrein'的葡萄酒類型，而是輸入了下列內容(注意包括其中的兩個標點符號)：

lagrein' or 1=1;

現在，你繼續使用前面固定的部分來構造你的查詢(在此，我們僅顯示$query變量的結果值)：

SELECT * FROM wines WHERE variety = '

然后，你使用包含用戶輸入內容的變量的值與之進行連接(在此，以粗體顯示)：

SELECT * FROM wines WHERE variety = 'lagrein' or 1=1;

最后，添加上下面的下引號：

SELECT * FROM wines WHERE variety = 'lagrein' or 1=1;'

于是，這個查詢結果與你的期望會相當不同。事實上，現在你的查詢包含的不是一條而是兩條指令，因為用戶輸入的最后的分號已經結束了第一條指令(進行記錄選擇)從而開始了一條新的指令。在本例中，第二條指令，除了一個簡單的單引號之外別無意義;但是，第一條指令也不是你所想實現的。當用戶把一個單引號放到他的輸入內容的中間時，他結束了期望的變量的值，并且引入了另一個條件。因此，不再是檢索那些variety為'lagrein'的記錄，而是在檢索那些滿足兩個標準中任何一個(第一個是你的，而第二個是他的-variety為'lagrein'或1等于1)的記錄。既然1總是1，因此，你會檢索到所有的記錄!

你可能反對：我不會使用雙引號來代替單引號來描述用戶提交的變量嗎?不錯，這至少可以減慢惡意用戶的攻擊。(在以前的文章中，我們提醒過你：應該禁止所有對用戶的錯誤通知信息。如果在此生成一條錯誤消息，那么，它有可能恰恰幫助了攻擊者-提供一個關于他的攻擊為什么失敗的具體的解釋。)

在實踐中，使你的用戶能夠看到所有的記錄而不只是其中的一部分乍看起來似乎不太費事，但實際上，這的確費事不少;看到所有的記錄能夠很容易地向他提供有關于該表格的內部結構，從而也就向他提供了使其以后實現更為惡毒目的的一個重要參考。如果你的數據庫中不是包含顯然無害的酒之類信息而是包含例如一個含有雇員年收入的列表，那么，剛才描述情形會是特別真實的。

而從理論角度分析，這種攻擊也的確是一件很可怕的事情。由于把意外的內容注入到你的查詢中，所以，此用戶能夠實現把你的數據庫存取轉化為用于實現他自己的目的。因此現在，你的數據庫已經對他打開-正如對你敞開一樣。

四、 PHP和MySQL注入

如我們前面所描述的，PHP，從本身設計來說，并沒有做什么特別的事情-除了按照你的指示操作之外。因此，如果為惡意用戶所用，它也只是按照要求'允許'特別設計的攻擊-例如我們前面所描述的那樣。

我們將假定，你不會故意地或甚至是偶然地構造一個具有破壞性效果的數據庫查詢-于是，我們假定問題出在來自你的用戶的輸入方面。現在，讓我們來更為細致地分析一下用戶可能向你的腳本提供信息的各種途徑。

五、 用戶輸入的類型

如今，用戶能夠影響你的腳本的行為已變得越來越復雜。

用戶輸入最明顯的來源當然是表單上的一個文本輸入域。使用這樣的一個域，你簡直是在故意教唆一個用戶輸入任意數據。而且，你向用戶提供了一個很大的輸入范圍;沒有什么辦法能夠使你提前限制一個用戶能夠輸入的數據類型(盡管你能夠選擇限制它的長度)。這正是絕大多數的注入式攻擊源主要來自于無防備的表單域的原因。

但是，還存在其它的攻擊源，并且稍加思考你就會想到的一種潛于表單后臺的技術-POST方法!通過簡單地分析顯示在瀏覽器的導航工具欄中的URI，一個善于觀察的用戶能夠很容易地看出是什么信息傳遞到了一個腳本。盡管典型情況下這樣的URI是以編程方式生成的，但是，沒有什么辦法能夠阻止一個惡意的用戶簡單地把一個帶有一個不適當的變量值的URI輸入到一個瀏覽器中-而這樣潛在地打開一個可能會被其濫用的數據庫。

限制用戶輸入內容的一個常用策略是在一個表單中提供一個選擇框，而不是一個輸入框。這種控件能夠強制用戶從一組預定義的值中進行選擇，并且能夠在一定程度上阻止用戶輸入期望不到的內容。但是正如一個攻擊者可能'哄騙'一個URI(也即是，創建一個能夠模仿一個可信任的卻無效的URI)一樣，他也可能模仿創建你的表單及其自己的版本，并因此在選項框中使用非法的而不是預定義的安全選擇。要實現這點是極其簡單的;他僅需要觀察源碼，然后剪切并且粘貼該表單的源代碼-然后一切為他敞開大門。

在修改該選擇之后，他就能夠提交表單，并且他的無效的指令就會被接受，就象它們是原始的指令一樣。因此，該用戶可以使用許多不同的方法試圖把惡意的代碼注入到一個腳本中。

http://blog.csdn.net/wast/archive/2007/01/22/1490118.aspx