在本系列文章中，我們將全面**如何在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)一樣，他也可能模仿創立你的表單及其自己的版本，並因此在選項框中應用非法的而不是預定義的安全選擇。要實現這點是極其簡略的；他僅需要觀察原始碼，然後剪下並且貼上該表單的源**-然後一切為他敞開大門。
在修正該選擇之後，他就能夠提交表單，並且他的無效的指令就會被接收，就象它們是原始的指令一樣。因此，該使用者可以應用很多不同的方法試圖把惡意的**注進到乙個指令碼中。
在PHP中全面阻止SQL注入式攻擊
在本系列文章中，我們將全面 如何在php開發環境中全面阻止sql注入式攻擊，並給出乙個具體的開發示例。一 引言 php是一種力量強大但相當容易學習的伺服器端指令碼語言，即使是經驗不多的程式設計師也能夠使用它來建立複雜的動態的web站點。然而，它在實現網際網路服務的秘密和安全方面卻常常存在許多困難。在...
在PHP中全面阻止SQL注入式攻擊之一
在本系列文章中，我們將全面 如何在php開發環境中全面阻止sql注入式攻擊，並給出乙個具體的開發示例。一 引言 php是一種力量強大但相當容易學習的伺服器端指令碼語言，即使是經驗不多的程式設計師也能夠使用它來建立複雜的動態的web站點。然而，它在實現網際網路服務的秘密和安全方面卻常常存在許多困難。在...
在PHP中全面阻止SQL注入式攻擊之三
一 建立乙個安全抽象層 我們並不建議你手工地把前面介紹的技術應用於每乙個使用者輸入的例項中，而是強烈推薦你為此建立乙個抽象層。乙個簡單的抽象是把你的校驗方案加入到乙個函式中，並且針對使用者輸入的每一項呼叫這個函式。當然，我們還可以建立一種更複雜的更高一級的抽象 把乙個安全的查詢封裝到乙個類中，從而應...