从WAF攻防角度重看sql注入
攻防都是在对抗中逐步提升的，所以如果想攻，且攻得明白，就必须对防有深刻的了解
sql注入的大体流程
- Fuzz测试找到注入点
- 对注入点进行过滤检测，及WAF绕过
- 构建payload，对数据库进行脱裤，甚至getshell
sql注入流程分析
- sql注入，最初没有防护的时候，就只要能成功拼接sql语句，就可以进行sql注入
- 先对注入点进行判断，是字符型还是整型。
对于整型一般是直接拼接sql，而对于字符型的一般是先要闭合掉单引号，或者双引号，还有一种存在利用逻辑漏洞闭合sql语句的，等下一起分析了
所以这里先通过加 ” ‘ 进行判断，得出是字符型注入。
引号闭合方式：1. 利用注释符 mysql中一般用的是–+和#，不过如果是GET传参，需要将#先进行URL编码，不然会被当作url中的hash结构，–+中的+是随意的，只要–后跟一个字符就可以，如果利用的是GET传参，也需要将空格进行url编码，不然会被浏览器自动剔除最末 尾空白符的操作给疑惑到，一般用– -更方便，反正最后一个-也会被当作sql注释后的内容
2. 利用逻辑，例如 id=’ or {payload} or ‘1’=’1 这样的话最后拼接到数据库中就是select * from user where id=’$id’>select * from user where id=” or {payload} or ‘1’=’1′;从而完成引号闭合 3 其他：利用逻辑将’转义 select * from user where id=’$username’ and pass=’$password’;>select * from user where id=’asdasd’ and pass=’ or 1=1#’;在这里，由于第二个引号被转义，所以第一个引号和第三个引号和中间字符组成一个字符串，也就是id最终是{ asdasd’ and pass= },最终得以绕过
防护1：1. 对于整形数据，php中可以用intval()将输入流先进行转换 2.对于字符型参数，可以用合理利用addslashes()对其中的单引号和双引号进行转义，合理是要求对任何进入程序的输入流都进行先转义，包括数据库，防止二次注入 3.合理利用编码，防止编码注入
- 确认注入点后,确定字段数
确定字段数为3
- 开始构造payload
- id=0′ union select 1,2,3–+
确认回显位置为2，3参数的位置
- id=0′ union select 1,database(),3–+
获取数据库名
- id=0′ union select 1,database(),(select group_concat(column_name) from information_schema.columns where table_name=’users’ and table_schema=database())–+
利用group_concat一下获取该数据库中的所有的表，当然也可以利用limit一个个来，这里最好限定下库名，防止其他库中也有同名的表
- id=0′ union select 1,(select group_concat(username) from users),(select group_concat(password) from users)–+
最终成功获取同表中的所有数据
- id=0′ union select 1,2,3–+
如果想获取其他表或者其他库中的文件，修改下参数即可，其他库中的表 {库名.表名}，而用户都放在mysql数据库中，如果有权限可以任意篡改，甚至还可以写shell，操作多多。
防护2：过滤关键字，如select|information|table|column|from|union等，但黑名单总是存在被绕过的可能
猜想：可不可以利用mysql支持hex编码，先将sql写入到文件，再执行？
sql注入防护-采用预编译
从上面的流程可以看出，最基本的防护就是采用黑名单模式过滤关键字符或字符串，但黑名单往往随着sql语法的支持增加，黑名单的效果会下降。
预编译其实是先通过了编译，建立了AST语法树，所以后续的操作只是像空格中填充东西而不影响句子的执行结构。
用了预编译就一定安全了嘛？你真的会用预编译嘛？
- 错误顺序导致无效的预编译
$query = "select balabala from table1 where 1=$_GET[‘id’]";
$row = $db->prepare($query);
$row->execute();
可以看到在这里，先把变量拼接到sql语句，再进行预编译是无效的，这样对应的恶意语法树还是解析了
- 模拟预编译导致的宽字节注入
PDO中有一个PDO::ATTR_EMULATE_PREPARES配置，用来控制是模拟预编译，其实就是对sql的特殊字符进行了转义
如果该数据的编码是GBK的话，就有可能造成sql的宽字节注入
其实这里我也没明白为什么会搞一个模拟预编译，为了性能？
- 支持多行代码执行的预编译导致的sql注入（没有过滤分号）
Set @x=0x31
Prepare a from “select balabala from table1 where 1=?”
Execute a using @x
由于sql中默认支持hex编码，所以将目标代码进行hex编码绕过检测，然后就可以在预编译时期造成sql执行。
对于动态代码，或支持动态代码的操作或者函数一定要小心。动态代码字符串就可以利用奇奇怪怪的编码造成千人千面的效果，在终点再转换为争取的代码执行，以此来绕过防护
sql注入绕WAF
其实上面说的那么多，很多就是软件WAF的工作原理。
所以这里绕过WAF，也就相当于是对上面的总结。
-
WAF检测关键字符串和关键字符
对于关键字符串，一般采用替代的方法，sql中有很多不为人知的用法，例如limit 1,1 如果对逗号进行了绕过还可以采用 limit 1 offset 1,如果对limit进行了限制，还可以用from to来，前提是对sql语法足够熟悉。而对于空格，一般直接用Fuzz测试即可
-
过滤了关键的库名
例如上面用的information库，其实sys中的某些表或视图也保存了相关的表名和字段名，也就可以用来做替换
-
利用WAF检测点来绕过
例如某WAF只对GET请求的参数进行了sql检测，而同时后端用的是$_REQUEST来获取参数，这个时候就可以用POST进行绕过，应该$_REQUEST可以也可以获取POST参数，但WAF不会对POST参数进行检测
-
利用WAF的多重解码，进行编码注入
有些WAF为了防止编码注入，会先检测一部分，然后对输入流进行解码，再检测另一部分，利用解码，可以绕过第一部分的恶意字符。除非是对解码前后都进行了相同的完全的过滤。但这样处理编码，无异于对性能是个巨大的浪费。
-
利用WAF只检测部分数据
有些WAF为了性能，不可能对全部的数据进行检测，例如上传一个大的文件，不可能对文件进行全面检测，所以往往只检测前几十个字节，而我们可以把恶意数据放在检测区间的后面，来绕过检测。
-
HTTP协议兼容性：HTTP Body多样性
-
HPP参数污染
HPP是HTTP Parameter Pollution的缩写，意为HTTP参数污染。
在ASPX中，有一个比较特殊的HPP特性，当GET/POST/COOKIE同时提交的参数id，服务端接收参数id的顺序GET,POST,COOKIE，中间通过逗号链接，于是就有了这个idea。
这些都是应对于软件WAF的，还有云WAF和硬件WAF，回头再说
