SQL注入其實很簡單，別一不留神就被利用了

SQL注入這個詞相信你們應該都不陌生，並且每一年都會有這樣子的事情發生，下面我先帶你們回憶11年兩期起比較經典的案例事件：

一、SONY索尼事件
2011年4月，著名的匿名者組織Anonymous注入SONY一個網站，一星期後才被發現7千萬的用戶我的信息，其中包括姓名、地址、E-mail、出生日期、用戶名、密碼以及購買記錄的數據信息，隨後的一些其餘服務器也被相繼攻破

二、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參數的傳遞方式將防止利用單引號和連字符實施注入。此外，它還使得數據庫權限能夠限制到只容許特定的存儲過程執行，全部的用戶輸入必須聽從被調用的存儲過程的安全上下文，這樣就很難再發生注入式了。