SQL注入漏洞
SQL注入经常出现在登陆页面、和获取HTTP头(user-agent/client-ip等)、订单处理等地方，因为这几个地方是业务相对复杂的，登陆页面的注入现在来说大多数是发生在HTTP头里面的client-ip和x-forward-for。
1.普通注入
普通注入是指最容易利用的SQL注入漏洞，比如直接通过注入union查询就可以查询数据库，一般的SQL注入工具也能够非常好地利用。普通注入有int型和string型
测试环境搭建：
数据库名为test 数据库表名userinfo 以下时数据库数据
测试出SQL注入漏洞
从上面我们可以看出我们使用union查询到当前的用户
从上面的测试代码中可以发现，数据库操作存在一些关键字，比如 select from、mysql_connect、mysql_query、mysql_fetch_row等，数据库的查询方式还有update、insert、delete 我们在做白盒审计时，只需要查找这些关键字，即可定向挖掘SQL注入漏洞
2编码注入
程序在进行一些操作之前经常会进行一些编码处理，而做编码处理地函数也是存在问题地，通过输入转码函数不兼容地特殊字符，可以导致输出地字符变成有害地数据，在SQL注入里，最常见地编码注入是Mysql宽字节以及urldecode/rawurldecode函数导致的
2.1宽字节注入
在使用PHP连接mysql的时候，当设置set character_set_client=gbk 时会导致一个编码转换的注入问题，也就是我们所熟悉的宽字节注入。当存在宽字节注入漏洞时，注入参数里带入%df%27，即可把成程序中过滤的(%5c)吃掉。
举个例子
我们可以看一个例子当我id=1加上‘号提交的时候 它将’号前面加了很明显这样时注入不成功的。
但是我们如果提交/index.php?id=1%df’ and 1=1%23 由于单引号会被自动转义成‘ ，前面的%df和转义反斜杠(%5c)组合成了%df%5c，就是一个字，这时候单引号依然存在于是就成功闭合了前面的单引号
出现这个漏洞的原因时PHP连接mysql的时候执行了如下设置
Set character_set_client=gbk
告诉mysql服务器客户端来源数据编码时GBK，然后mysql服务器对查询语句进行GBK转码导致反斜杠被%df吃掉，而一般都不是直接设置character_set_client=gbk
告诉mysql服务器客户端来源数据编码时GBK，然后Mysql服务器对查询语句进行GBK转码导致反斜杠被%df吃吃掉，而一般都不是直接设置character_set_client=gbk，通常设置方法时SET NAMES ‘gbk’,但其实SET NAMES ‘gbk‘不过是比character_set_client=gbk多干了两件事而已，SET NAMES ’gbk‘等同于如下代码：
SET
Character_set_connection=’gbk’,
Character_set_results=’gbk’,
Character_set_client=gbk
这同样也是存在漏洞的,另外官方建议使用mysql_set_charset方式设置编码，不幸的时它也知识调用了SET NAMES，所以效果也是一样的。不过mysql_set_charset调用SET NAMES之后还记录了当前的编码，留着给后面mysql_real_escape_string处理字符串的时候使用，所以在后面只要合理地使用mysql_real_escape_string还是可以解决这个漏洞的，关于这个漏洞的解决方法:
（1） 在执行查询之前先执行SET NAMES ‘gbk‘，character_set_client=binary设置character_set_client为binary。
（2） 使用mysql_set_chharset(‘gbk‘)设置编码，然后使用mysql_real_escape_string()函数被参数过滤。
（3） 使用PDO方式，在PHP5.3.6及以下版本需要设置setAttribute(PDO::ATTR_EMULATE_PREPATES,FALSE);来禁用prepared statements的仿真效果
宽字节注入挖掘关键字:
SET NAMES
Character_set_client=gbk
Mysql_set_charset(‘gbk‘)
环境搭建
数据库沿用普通注入里面的数据库
测试出SQL注入漏洞
mysql的特性，因为gbk是多字节编码，两个字节代表一个汉字，所以%df和后面的也就是%5c变成了一个汉字“運”，而’逃逸了出来。
宽字节挖掘关键字
SET NAMES
Character_set_clent=gbk
Mysql_set_charset(‘gbk’)
Mysql_set_charset(‘gbk‘)
2.2二次urldecode注入
只要字符被进行转换就有可能产生漏洞，现在web程序大多都会进行参数过滤，通常使用addslashes()、mysql_real_escape_string()、mysql_escape_string()函数或开启GPC的方式进行防止注入，也就是给单引号、双引号、反斜杠和NULL加上反斜杠转义。如果某处试用了urldecode或者rawurldecode函数，则会导致二次解码生成单引号而引发注入。原理是我们提交参数到webserver时，webserver会自动解码一次
测试环境搭建：
我们可以看url部分%25经过第一次转码后的结果时%所以拼接后面的成为%27 而%27再经过urldecode经过第二次转码成为单引号成功引发注入
二次urldecode挖掘关键字
Urldecode
Rawurldecode
3.漏洞防范
在PHP中可以利用魔术引号来解决，不过魔术引号在PHP5.4后被取消，并且gpc在遇到int型注入时也会显得不那么给力了，所以通常用的多的还是过滤函数和类，像discuz、dedecms、phpcms等程序里面都使用过滤类，不过如果单纯的过滤函数写的不够严谨，也会出现绕过的情况，像这三套程序都存在绕过问题。当然最好的解决方案还是利用预编译的方式。
1. gpc/rutime 魔术引号
通常数据污染有两种方式，一种格式应用被动接受参数，类似于GET、POST等；还有一种是主动红红火火去参数，类似于读取远程页面或者文件内容等。所以放置SQL注入的方法就是要守住这两条路。Magic_quotes_gpc负责对GET、POST、COOKIE的值进行过滤，magiic_quotes_runtime对从数据库或者文件中获取的数据进行过滤 开启这两个选项之后能防住部分SQL注入 在int型注入上是没有多大作用的。
2.过滤类函数和类
(1)addslashes函数
Addslashhes函数过滤的值范围和GPC时一样的，即单引号(‘)、双引号(“)、反斜杠()及空字符NULL，它只是一个简单的检查参数的函数，大多数程序使用它实在程序的入口。
(2)mysql_[real_]escape_string函数
Mysql_escape_string和mysql_real_e3.scape_string函数都是对字符串进行过滤，在PHP4.0.3以上版本才有。
(3)intval等字符转换
以上里昂中过滤方式，在int类型注入时效果并不好，比如可以通过报错或者盲注方式绕过，这时候intval等函数就起作用了，intval的作用是将变量转换成int类型，这里距离intval是要表达的一种方式，一种利用参数类型白名单的方式来防止漏洞，对应的还有好很多如floatval等
2. PDO prepare预编译
待更新…….