前言
SQL注入原理之前已經研究過了，感興趣的師傅可以去看一下SQL注入天書，這裏不詳細介紹了，簡單講一下再代碼審計中容易出現的SQL注入類型，只是簡單歸納一下書裏的知識
SQL注入位置
登陸頁面、獲取HTTP頭處理函數、訂單處理、查詢搜索，用戶管理操作頁面等，登陸頁面大多發生在HTTP頭的client-ip和x-forward-for,一般用於記錄IP地址，在訂單頁面因爲要和很多頁面交互往往很複雜，也常常出現二次注入
代碼審計基本注入類型
普通注入
字符型 1' and '1' = '1' 、數字型 1 and 1=1
寬字節注入
PHP連接數據庫時候，當設置 set character_set_chient=gbk 時候或當我們看到的變量有時會被addslashes函數過濾，會導致編碼注入問題。如果數據庫是用GBK編碼處理參數的，我們可以在參數中帶入%df%27 '或%df \ '，編碼爲%df%5c%27，%df%57會被認爲是一箇中文“運”，這樣單引號之前的轉義符號“\”就被喫調了，變成了“運’”轉義失敗，mysql在解讀時會無視新字節，使得我們的單引號 ' 生效。
在SQLMAP加腳本參數，或者直接在後邊加%df'直接跑
--tamper unmagicquotes --dbs --hex
設置SET NAMES 'gbk'也一樣有漏洞出現,只是不過多幹兩步
SET character_set_connection='gbk', character_set_results='gbk', character_set_client=gbk
代碼審計的時候查找關鍵字
SET NAMES
character_set_client=gbk
mysql_set_charset('gbk')
二次注入
傳入數據庫再取出調用的情況下就可能會造成漏洞，現在web程序經常會使用addslashes()，mysql_real_escape_string()，mysql_escape_string()或開啓GPC的方式轉義特殊字符。如果某處使用了urldecode或rawurldecode,就有可能出現二次編碼注入，比如我們提交?id=1%2527,第一次解碼後是?id=1%27，因爲%25解碼後是%，然後1%27就存入了數據庫，再調用解碼的時候，1%27就變成了1'，傳入的時候沒有單引號，調用的時候單引號就出現了引發注入
在代碼審計中我們就可以搜索urldecode或rawurldecode來查找有沒有二次注入的漏洞