在本系列文章中我們將全面探討如何在PHP開發環境中全面阻止SQL注入式攻擊並給出一個具體的開發示例
一 引言
PHP是一種力量強大但相當容易學習的服務器端腳本語言即使是經驗不多的程序員也能夠使用它來創建復雜的動態的web站點然而它在實現因特網服務的秘密和安全方面卻常常存在許多困難在本系列文章中我們將向讀者介紹進行web開發所必需的安全背景以及PHP特定的知識和代碼你可以借以保護你自己的web應用程序的安全性和一致性首先我們簡單地回顧一下服務器安全問題展示你如何存取一個共享宿主環境下的私人信息使開發者脫離開生產服務器維持最新的軟件提供加密的頻道並且控制對你的系統的存取
然後我們討論PHP腳本實現中的普遍存在的脆弱性我們將解釋如何保護你的腳本免於SQL注入防止跨站點腳本化和遠程執行並且阻止對臨時文件及會話的劫持
在最後一篇中我們將實現一個安全的Web應用程序你將學習如何驗證用戶身份授權並跟蹤應用程序使用避免數據損失安全地執行高風險性的系統命令並能夠安全地使用web服務無論你是否有足夠的PHP安全開發經驗本系列文章都會提供豐富的信息來幫助你構建更為安全的在線應用程序
二 什麼是SQL注入
如果你打算永遠不使用某些數據的話那麼把它們存儲於一個數據庫是毫無意義的因為數據庫的設計目的是為了方便地存取和操作數據庫中的數據但是如果只是簡單地這樣做則有可能會導致潛在的災難這種情況並不主要是因為你自己可能偶然刪除數據庫中的一切而是因為當你試圖完成某項無辜的任務時你有可能被某些人所劫持使用他自己的破壞性數據來取代你自己的數據我們稱這種取代為注入
其實每當你要求用戶輸入構造一個數據庫查詢你是在允許該用戶參與構建一個存取數據庫服務器的命令一位友好的用戶可能對實現這樣的操作感覺很滿意然而一位惡意的用戶將會試圖發現一種方法來扭曲該命令從而導致該被的扭曲命令刪除數據甚至做出更為危險的事情作為一個程序員你的任務是尋找一種方法來避免這樣的惡意攻擊
三 SQL注入工作原理
構造一個數據庫查詢是一個非常直接的過程典型地它會遵循如下思路來實現僅為說明問題我們將假定你有一個葡萄酒數據庫表格wines其中有一個字段為variety（即葡萄酒類型）
提供一個表單允許用戶提交某些要搜索的內容讓我們假定用戶選擇搜索類型為lagrein的葡萄酒
檢索該用戶的搜索術語並且保存它通過把它賦給一個如下所示的變量來實現
$variety = $_POST[variety];
因此變量$variety的值現在為
lagrein
然後使用該變量在WHERE子句中構造一個數據庫查詢
$query = SELECT * FROM wines WHERE variety=$variety;
所以變量$query的值現在如下所示
SELECT * FROM wines WHERE variety=lagrein
把該查詢提交給MySQL服務器
MySQL返回wines表格中的所有記錄其中字段variety的值為lagrein
到目前為止這應該是一個你所熟悉的而且是非常輕松的過程遺憾的是有時我們所熟悉並感到舒適的過程卻容易導致我們產生自滿情緒現在讓我們再重新分析一下剛才構建的查詢
你創建的這個查詢的固定部分以一個單引號結束你將使用它來描述變量值的開始
$query = SELECT * FROM wines WHERE variety = ;
使用原有的固定不變的部分與包含用戶提交的變量的值
$query = $variety;
然後你使用另一個單引號來連接此結果描述該變量值的結束
$ query = ;
於是$query的值如下所示
SELECT * FROM wines WHERE variety = lagrein
這個構造的成功依賴用戶的輸入在本文示例中你正在使用單個單詞(也可能是一組單詞)來指明一種葡萄酒類型因此該查詢的構建是無任何問題的並且結果也會是你所期望的一個葡萄酒類型為lagrein的葡萄酒列表現在讓我們想象既然你的用戶不是輸入一個簡單的類型為lagrein的葡萄酒類型而是輸入了下列內容(注意包括其中的兩個標點符號)
lagrein or =;
現在你繼續使用前面固定的部分來構造你的查詢(在此我們僅顯示$query變量的結果值)
SELECT * FROM wines WHERE variety =
然後你使用包含用戶輸入內容的變量的值與之進行連接(在此以粗體顯示)
SELECT * FROM wines WHERE variety = lagrein or =;
最後添加上下面的下引號
SELECT * FROM wines WHERE variety = lagrein or =;
於是這個查詢結果與你的期望會相當不同事實上現在你的查詢包含的不是一條而是兩條指令因為用戶輸入的最後的分號已經結束了第一條指令(進行記錄選擇)從而開始了一條新的指令在本例中第二條指令除了一個簡單的單引號之外別無意義但是第一條指令也不是你所想實現的當用戶把一個單引號放到他的輸入內容的中間時他結束了期望的變量的值並且引入了另一個條件因此不再是檢索那些variety為lagrein的記錄而是在檢索那些滿足兩個標准中任何一個（第一個是你的而第二個是他的variety為lagrein或等於）的記錄既然總是因此你會檢索到所有的記錄！
你可能反對我不會使用雙引號來代替單引號來描述用戶提交的變量嗎？不錯這至少可以減慢惡意用戶的攻擊(在以前的文章中我們提醒過你應該禁止所有對用戶的錯誤通知信息如果在此生成一條錯誤消息那麼它有可能恰恰幫助了攻擊者提供一個關於他的攻擊為什麼失敗的具體的解釋)
在實踐中使你的用戶能夠看到所有的記錄而不只是其中的一部分乍看起來似乎不太費事但實際上這的確費事不少看到所有的記錄能夠很容易地向他提供有關於該表格的內部結構從而也就向他提供了使其以後實現更為惡毒目的的一個重要參考如果你的數據庫中不是包含顯然無害的酒之類信息而是包含例如一個含有雇員年收入的列表那麼剛才描述情形會是特別真實的
而從理論角度分析這種攻擊也的確是一件很可怕的事情由於把意外的內容注入到你的查詢中所以此用戶能夠實現把你的數據庫存取轉化為用於實現他自己的目的因此現在你的數據庫已經對他打開正如對你敞開一樣
四 PHP和MySQL注入
如我們前面所描述的PHP從本身設計來說並沒有做什麼特別的事情除了按照你的指示操作之外因此如果為惡意用戶所用它也只是按照要求允許特別設計的攻擊例如我們前面所描述的那樣
我們將假定你不會故意地或甚至是偶然地構造一個具有破壞性效果的數據庫查詢於是我們假定問題出在來自你的用戶的輸入方面現在讓我們來更為細致地分析一下用戶可能向你的腳本提供信息的各種途徑
五 用戶輸入的類型
如今用戶能夠影響你的腳本的行為已變得越來越復雜
用戶輸入最明顯的來源當然是表單上的一個文本輸入域使用這樣的一個域你簡直是在故意教唆一個用戶輸入任意數據而且你向用戶提供了一個很大的輸入范圍沒有什麼辦法能夠使你提前限制一個用戶能夠輸入的數據類型(盡管你能夠選擇限制它的長度)這正是絕大多數的注入式攻擊源主要來自於無防備的表單域的原因
但是還存在其它的攻擊源並且稍加思考你就會想到的一種潛於表單後台的技術POST方法！通過簡單地分析顯示在浏覽器的導航工具欄中的URI一個善於觀察的用戶能夠很容易地看出是什麼信息傳遞到了一個腳本盡管典型情況下這樣的URI是以編程方式生成的但是沒有什麼辦法能夠阻止一個惡意的用戶簡單地把一個帶有一個不適當的變量值的URI輸入到一個浏覽器中而這樣潛在地打開一個可能會被其濫用的數據庫
限制用戶輸入內容的一個常用策略是在一個表單中提供一個選擇框而不是一個輸入框這種控件能夠強制用戶從一組預定義的值中進行選擇並且能夠在一定程度上阻止用戶輸入期望不到的內容但是正如一個攻擊者可能哄騙一個URI(也即是創建一個能夠模仿一個可信任的卻無效的URI)一樣他也可能模仿創建你的表單及其自己的版本並因此在選項框中使用非法的而不是預定義的安全選擇要實現這點是極其簡單的他僅需要觀察源碼然後剪切並且粘貼該表單的源代碼然後一切為他敞開大門
在修改該選擇之後他就能夠提交表單並且他的無效的指令就會被接受就象它們是原始的指令一樣因此該用戶可以使用許多不同的方法試圖把惡意的代碼注入到一個腳本中
From:http://tw.wingwit.com/Article/program/PHP/201311/20773.html
