所谓SQL注入，就是通过把SQL命令插入到Web表单提交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令。
一般SQLI出现在登陆页面，获取HTTP头（user-agent,client-ip等），订单处理等处。
- 普通注入：
如下代码，
<?php
$uname = $_GET['name'] ;
$sql = "SELECT * FROM user where name=$uname";
$conn=mysql_connect('localhost','root','root');
mysql_select_db("userinfo",$conn);
$result=mysql_query($sql,$conn);
print_r('now sql is:'.$sql.'<br/>result is:');
print_r(mysql_fetch_row($result));
?>
uname变量没有经过处理，便拼接到数据库指令之中，造成了sql注入风险。
所以我们在审计的时候应该关注一些重点关键字，就可以帮助我们高效的发掘漏洞。
| 关键字 |
|---|
| select from |
| mysql_connect |
| mysql_query |
| mysql_fetch_row |
| ... |
- 编码注入：
宽字节注入
如下代码：
<?php
$conn=mysql_connect('localhost','root','root');
mysql_select_db("userinfo",$conn);
mysql_query("SET NAMES 'GBK'");
$uid=addslashes($_GET['id']);
$sql="SELECT * FROM user where name='$uid'";
$result=mysql_query($sql,$conn);
print_r('now sql is:' .$sql. '<br/>result is:');
print_r(mysql_fetch_row($result));
mysql_close();
?>
这里加入了addslashes函数，对部分字符进行了转义，比如：
这里主要是存在一个问题是，编码设置成了GBK，这里会导致成编码注入，也就是宽字节注入，GB2312、GBK、GB18030、BIG5、Shift_JIS等这些都是常说的宽字节，实际上只有两字节。宽字节带来的安全问题主要是吃ASCII字符(一字节)的现象，这里addslashes会将引号后面加入反斜杠（\），会造成我们无法利用，GBK的编码范围是0x8140~0xFEFE（不包括xx7F），在遇到%df(ascii(223)) >ascii(128)时自动拼接%5c，因此吃掉‘\’，而%27、%20小于ascii(128)的字符就保留了，而反斜杠的编码是%5c，而%df%5c是汉字“運”，所以我们在单引号前加上%df即可将后面的单引号吞掉，造成引号成功逃脱转义：
GBK编码第一字节（高字节）的范围是0x81~0xFE,第二字节（低字节）的范围是0x40~0x7E与0x80~0xFE，这样的十六进制表示。而\符号的十六进制表示为0x5C，正好在GBK的低字节中，如果之前有一个高字节，那么正好会被组成一个合法字符,GB2312是被GBK兼容的，它的高位范围是0xA1~0xF7，低位范围是0xA1~0xFE（0x5C不在该范围内），因此不能使用编码吃掉%5c，其它的宽字符集也是一样的分析过程，要吃掉%5c，只需要低位中包含正常的0x5c就行了。
这里一定要注意sql注入和xss不同，在xss中，把上面的PHP代码的GBK改为GB2312，在浏览器中处理行为同GBK，也许是由于GBK兼容GB2312，浏览器都做了同样的兼容:把GB2312统一按GBK行为处理
结果如下：
| 关键字 |
|---|
| SET NAMES |
| character_set_client=gbk |
| mysql_set_charset('gbk') |
二次urldecode注入
字符进行转换就会有可能产生漏洞，现在大多数web程序都会进行参数过滤，一般会选择addslashes() 等函数或者开启GPC来对特殊符号进行转义，如果某处使用了urldecode或者rawurldecode函数会导致二次解码生成单引号而引起注入。
测试代码：
<?php
$a=addslashes($_GET['p']);
$b=urldecode($a);
echo 'a='.$a;
echo "<br/>";
echo 'b='.$b;
?>
这里我们有两个变量，a变量是使用addslashes函数对get得到的p进行转义，b变量是对a进行urldecode的结果，由于使用了addslashes，所以我们的单引号后面加上了反斜杠：
但是由于urldecode函数的存在，我们可以构造如下利用过程：
?p=1%2527
由于浏览器自动进行了一次url解码，所以%25被解码为%，而又因为urldecode函数的作用，%27被解码为单引号（'）：
| 关键字 |
|---|
| urldecode |
| rawurldecode |
Base64编码注入
类似于URL编码注入，还有Base64编码注入，经过前端Base64转换后，参数被Base64加密，防御模块无法通过关键词分析出此参数的恶意字符。审计过程中遇到Base64_decode函数，之后没有做任何过滤，直接拼接到SQL语句中，就可能导致SQL注入漏洞。
参考文章：
