一、 引言

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

　　然后，我們討論P(yáng)HP腳本實(shí)現(xiàn)中的普遍存在的脆弱性。我們將解釋如何保護(hù)你的腳本免于SQL注入，防止跨站點(diǎn)腳本化和遠(yuǎn)程執(zhí)行，并且阻止對(duì)臨時(shí)文件及會(huì)話的"劫持"。

　　在最后一篇中，我們將實(shí)現(xiàn)一個(gè)安全的Web應(yīng)用程序。你將學(xué)習(xí)如何驗(yàn)證用戶身份，授權(quán)并跟蹤應(yīng)用程序使用，避免數(shù)據(jù)損失，安全地執(zhí)行高風(fēng)險(xiǎn)性的系統(tǒng)命令，并能夠安全地使用web服務(wù)。無論你是否有足夠的PHP安全開發(fā)經(jīng)驗(yàn)，本系列文章都會(huì)提供豐富的信息來幫助你構(gòu)建更為安全的在線應(yīng)用程序。

　　二、 什么是SQL注入

　　如果你打算永遠(yuǎn)不使用某些數(shù)據(jù)的話，那么把它們存儲(chǔ)于一個(gè)數(shù)據(jù)庫是毫無意義的;因?yàn)閿?shù)據(jù)庫的設(shè)計(jì)目的是為了方便地存取和操作數(shù)據(jù)庫中的數(shù)據(jù)。但是，如果只是簡單地這樣做則有可能會(huì)導(dǎo)致潛在的災(zāi)難。這種情況并不主要是因?yàn)槟阕约嚎赡芘既粍h除數(shù)據(jù)庫中的一切;而是因?yàn)椋?dāng)你試圖完成某項(xiàng)"無辜"的任務(wù)時(shí)，你有可能被某些人所"劫持"-使用他自己的破壞性數(shù)據(jù)來取代你自己的數(shù)據(jù)。我們稱這種取代為"注入"。

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

　　三、 SQL注入工作原理

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

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

　　2. 檢索該用戶的搜索術(shù)語，并且保存它-通過把它賦給一個(gè)如下所示的變量來實(shí)現(xiàn)：

　　以下是代碼片段：

　　$variety = $_POST['variety'];

　　因此，變量$variety的值現(xiàn)在為：

　　lagrein

　　3. 然后，使用該變量在WHERE子句中構(gòu)造一個(gè)數(shù)據(jù)庫查詢：

　　以下是代碼片段：

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

　　所以，變量$query的值現(xiàn)在如下所示：

　　以下是代碼片段：

　　SELECT * FROM wines WHERE variety='lagrein'

　　4. 把該查詢提交給MySQL服務(wù)器。

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

　　到目前為止，這應(yīng)該是一個(gè)你所熟悉的而且是非常輕松的過程。遺憾的是，有時(shí)我們所熟悉并感到舒適的過程卻容易導(dǎo)致我們產(chǎn)生自滿情緒。現(xiàn)在，讓我們再重新分析一下剛才構(gòu)建的查詢。

　　1. 你創(chuàng)建的這個(gè)查詢的固定部分以一個(gè)單引號(hào)結(jié)束，你將使用它來描述變量值的開始：

　　以下是代碼片段：

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

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

　　以下是代碼片段：

　　$query .= $variety;

　　3. 然后，你使用另一個(gè)單引號(hào)來連接此結(jié)果-描述該變量值的結(jié)束：

　　以下是代碼片段：

　　$ query .= "'";

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

　　以下是代碼片段：

　　SELECT * FROM wines WHERE variety = 'lagrein'

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

　　lagrein' or 1=1;

　　現(xiàn)在，你繼續(xù)使用前面固定的部分來構(gòu)造你的查詢(在此，我們僅顯示$query變量的結(jié)果值)：

　　SELECT * FROM wines WHERE variety = '

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

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

　　最后，添加上下面的下引號(hào)：

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

　　于是，這個(gè)查詢結(jié)果與你的期望會(huì)相當(dāng)不同。事實(shí)上，現(xiàn)在你的查詢包含的不是一條而是兩條指令，因?yàn)橛脩糨斎氲淖詈蟮姆痔?hào)已經(jīng)結(jié)束了第一條指令(進(jìn)行記錄選擇)從而開始了一條新的指令。在本例中，第二條指令，除了一個(gè)簡單的單引號(hào)之外別無意義;但是，第一條指令也不是你所想實(shí)現(xiàn)的。當(dāng)用戶把一個(gè)單引號(hào)放到他的輸入內(nèi)容的中間時(shí)，他結(jié)束了期望的變量的值，并且引入了另一個(gè)條件。因此，不再是檢索那些variety為"lagrein"的記錄，而是在檢索那些滿足兩個(gè)標(biāo)準(zhǔn)中任何一個(gè)(第一個(gè)是你的，而第二個(gè)是他的-variety為"lagrein"或1等于1)的記錄。既然1總是1，因此，你會(huì)檢索到所有的記錄!

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

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

　　而從理論角度分析，這種攻擊也的確是一件很可怕的事情。由于把意外的內(nèi)容注入到你的查詢中，所以，此用戶能夠?qū)崿F(xiàn)把你的數(shù)據(jù)庫存取轉(zhuǎn)化為用于實(shí)現(xiàn)他自己的目的。因此現(xiàn)在，你的數(shù)據(jù)庫已經(jīng)對(duì)他打開-正如對(duì)你敞開一樣。

　　四、 PHP和MySQL注入

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

　　我們將假定，你不會(huì)故意地或甚至是偶然地構(gòu)造一個(gè)具有破壞性效果的數(shù)據(jù)庫查詢-于是，我們假定問題出在來自你的用戶的輸入方面?，F(xiàn)在，讓我們來更為細(xì)致地分析一下用戶可能向你的腳本提供信息的各種途徑。

　　五、 用戶輸入的類型

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

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

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

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

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

最新評(píng)論