前言
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来查找有没有二次注入的漏洞