SQL注入這個詞相信大家應該都不陌生，而且每年都會有這樣子的事情發生，下面我先帶大家回憶11年兩期起比較經典的案例事件：
1、SONY索尼事件
2011年4月，著名的匿名者組織Anonymous注入SONY一個網站，一星期後才被發現7千萬的用戶個人信息，其中包括姓名、地址、E-mail、出生日期、用戶名、密碼以及購買記錄的數據信息，隨後的一些其他服務器也被相繼攻破
2、CSDN數據泄露門
2011年底，國內各大網站被爆出“密碼泄露門”，最先公佈的是著名技術網站CSDN600萬賬戶和密碼泄露事件，網站由於存在SQL注入漏洞被利用並下載用戶數據庫，同時令人不解的是，網站對用戶的信息儲存竟然是明文
什麼是sql注入
SQL注入指的是發生在Web應用對後臺數據庫查詢語句處理存在的安全漏洞，簡單的說，就是在輸入字符串中嵌入SQL指令，在設計程序中忽略了對特殊字符串的檢查，這些嵌入的指令便會被誤認爲正常的SQL指令，在數據庫中執行，因此可以對後臺數據庫進行查看等工作，甚至破快後臺數據庫造成嚴重後果。
目前SQL注入大致分爲普通注入和盲注
- 普通注入：根據後臺數據庫提示有價值的錯誤信息進行注入
- 盲注：有經驗的管理員在給出錯誤頁面時，沒有提供詳細的錯誤信息。測試者需要運用腳本通過僅有的判斷信息(比如時間差)對錶中的每一個字段進行探測，從而實現注入的技術。
(盲注的難度較大，但注入測試中經常會遇到)
SQL注入普遍的思路
- 發現SQL注入位置
- 判斷後臺數據庫類型
- 確定XP_CMDSHELL可執行情況
- 發現WEB虛擬目錄
- 上傳ASP腳本
- 得到管理員權限
SQL注入技術
- 強制產生錯誤
- 採用非主流通道技術
- 使用特殊的字符
- 使用條件語句
- 利用存儲過程
- 避開輸入過濾技術
- 推斷技術
普通注入示例
以著名的IBM公司所提供的SQL注入測試平臺
我們在這個網站上發現了一個登錄的頁面，現在我們在表單中的Username中輸入“admin'”，Password中輸入一樣的字段
點擊‘Login’登錄按鈕後，我們得到了一個報錯的頁面，根據提示“Syntax error (missing operator) in query expression 'username = 'admin'' AND password = 'admin'''.”我們可以猜測到大概的SQL語句應該是“select * from [users] where username=? and password=?”
我們返回登錄頁面在Username和Password中輸入“admin' or '1”然後再點擊登錄，我們就能意外的進入到登錄頁面之後了
是不是還是一臉懵，現在我們來解釋一下爲什麼會這樣，之所以能夠登陸成功，是因爲SQL的語句變成一下的語句：
select * from [users] where username= 'admin' or '1' and password='admin' or '1'
根據SQL中邏輯運算的優先級，or低於and，最後的or ‘1’永遠成立，所以該條件表達式結果爲True，此語句同等於下面的這條語句
select * from [users]
SQLmap工具注入示例
這個頁面通過了一次提交之後，我們得到了幾個信息，一個是提交的地址，還有就是cookie值，我們通過這幾個信息使用sqlmap工具項檢測一下有沒有sql的注入點
從檢測的結果中，我們看到了包含錯誤的SQL注入點，以及UNION查詢注入點，此外，還進一步的探測到了數據庫的版本是MySQL5.0的，Web應用平臺是PHP5.3.2/Apache2.2.14
使用SQLmap的“--dbs”選項，就可以根據所識別的不同數據庫管理平臺類型來探測包含的數據庫名稱，除了發現MySQL默認的系統數據庫information_schema之外，我們還發現了Web應用的數據庫dvwa
使用“-D dvwa --tables”選項指定了數據庫，然後獲得了此數據庫下的所有表，竟然表我們都能看到了，接下來我們來看看錶裏得到內容吧
加上“-D dvwa --tables -T users --columns --dump”選項前面的-D選項指定數據庫，後面-T指定表，最後我們看到了表中的內容，從中我們看到了一個admin的賬戶，將password放到在線解密MD5的網站上，我們的到密碼就是admin，拿着這個賬號密碼，輕鬆的進入到後臺中
SQL注入如何防範
通過一開始的兩起案件和後面我所示範的簡單注入，相信大家應該知道SQL的注入該有多危險了吧，下面給大家普及幾點防範SQL注入的方法：
輸入驗證
檢查用戶輸入的合法性，儘量的限制用戶輸入特殊的符號，確信輸入的內容只包含合法的數據。數據檢查應當在客戶端和服務器端都執行之所以要執行服務器端驗證，是爲了彌補客戶端驗證機制脆弱的安全性。
錯誤消息處理
防範SQL注入，還要避免出現一些詳細的錯誤消息，因爲可以利用這些消息。要使用一種標準的輸入確認機制來驗證所有的輸入數據的長度、類型、語句、企業規則等。
加密處理
在一開始的CDNS例子中沒有加密的數據就直接被利用了，但是加密了就不一定會解密成功，儘量不要用一些常見的加密算法，就算用也要使用32位以上的加密算法，將用戶登錄名稱、密碼等數據加密保存。加密用戶輸入的數據，然後再將它與數據庫中保存的數據比較，這相當於對用戶輸入的數據進行了“消毒”處理，用戶輸入的數據不再對數據庫有任何特殊的意義，從而也就防止了注入SQL命令。
存儲過程來執行所有的查詢
SQL參數的傳遞方式將防止利用單引號和連字符實施注入。此外，它還使得數據庫權限可以限制到只允許特定的存儲過程執行，所有的用戶輸入必須遵從被調用的存儲過程的安全上下文，這樣就很難再發生注入式了。