[WAF攻防]从WAF攻防角度重看sql注入

从WAF攻防角度重看sql注入

攻防都是在对抗中逐步提升的,所以如果想,且攻得明白,就必须对有深刻的了解

sql注入的大体流程

  1. Fuzz测试找到注入点
  2. 对注入点进行过滤检测,及WAF绕过
  3. 构建payload,对数据库进行脱裤,甚至getshell

sql注入流程分析

  • sql注入,最初没有防护的时候,就只要能成功拼接sql语句,就可以进行sql注入

    [WAF攻防]从WAF攻防角度重看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.合理利用编码,防止编码注入

  • 确认注入点后,确定字段数

    [WAF攻防]从WAF攻防角度重看sql注入

确定字段数为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)--+

      最终成功获取同表中的所有数据

      [WAF攻防]从WAF攻防角度重看sql注入

如果想获取其他表或者其他库中的文件,修改下参数即可,其他库中的表 {库名.表名},而用户都放在mysql数据库中,如果有权限可以任意篡改,甚至还可以写shell,操作多多。

防护2:过滤关键字,如select|information|table|column|from|union等,但黑名单总是存在被绕过的可能

猜想:可不可以利用mysql支持hex编码,先将sql写入到文件,再执行?

sql注入防护-采用预编译

从上面的流程可以看出,最基本的防护就是采用黑名单模式过滤关键字符或字符串,但黑名单往往随着sql语法的支持增加,黑名单的效果会下降。

预编译其实是先通过了编译,建立了AST语法树,所以后续的操作只是像空格中填充东西而不影响句子的执行结构。

用了预编译就一定安全了嘛?你真的会用预编译嘛?

  1. 错误顺序导致无效的预编译
$query = "select balabala from table1 where 1=$_GET[‘id’]";
$row = $db->prepare($query);
$row->execute();

可以看到在这里,先把变量拼接到sql语句,再进行预编译是无效的,这样对应的恶意语法树还是解析了

  1. 模拟预编译导致的宽字节注入

    [WAF攻防]从WAF攻防角度重看sql注入

    PDO中有一个PDO::ATTR_EMULATE_PREPARES配置,用来控制是模拟预编译,其实就是对sql的特殊字符进行了转义

    如果该数据的编码是GBK的话,就有可能造成sql的宽字节注入

其实这里我也没明白为什么会搞一个模拟预编译,为了性能?

  1. 支持多行代码执行的预编译导致的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,回头再说

上一篇:GUI菜单——菜单条、菜单、子条目之间关系


下一篇:VS2010-MFC(菜单:VS2010菜单资源详解)