[WAF攻防]从WAF攻防角度重看sql注入
从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,回头再说