制定
介绍
ngx_lua_waf 是一款基于 ngx_lua 的 web 应用防火墙，使用简单，高性能、轻量级。默认防御规则在 wafconf 目录中，摘录几条核心的 SQL 注入防御规则：
`select.+(from|limit)
(?:(union(.*?)select))
(?:from\W+information_schema\W)`
这边主要分享三种另类思路，Bypass ngx_lua_waf SQL 注入防御。
环境搭建
github 源码
ngx_lua_waf 安装部署，设置反向代理访问构造的 SQL 注入点
WAF 测试
ngx_lua_waf 是基于 ngx_lua 的，我们先通过一个测试用例来了解它是如何获取参数的。
首先看一下官方 API 文档，获取一个 uri 有两个方法：ngx.req.get_uri_args、ngx.req.get_post_args，二者主要的区别是参数来源有区别，ngx.req.get_uri_args 获取 uri 请求参数，ngx.req.get_post_args 获取来自 post 请求内容。
测试用例
`server { listen 80;
server_name localhost;
location /test {
content_by_lua_block {
local arg = ngx.req.get_uri_args()
for k,v in pairs(arg) do
ngx.say("[GET ] key:", k, " v:", v)
end
ngx.req.read_body()
local arg = ngx.req.get_post_args()
for k,v in pairs(arg) do
ngx.say("[POST] key:", k, " v:", v)
end
} }}`输出测试
通过这个测试，我们可以发现：
1、当提交同一参数 id，根据接收参数的顺序进行排序
2、当参数 id，进行大小写变换，如变形为 Id、iD、ID，则会被当做不同的参数，大小写敏感。
我们知道，window下 IIS+ASP/ASPX 大小写是不敏感的，
提交参数为：
?id=1&Id=2&iD=3&ID=4，
输出结果为：
1, 2, 3, 4
那么，当 nginx 反向代理到 IIS 服务器的时候，这就存在一个参数获取的差异，结合 HPP 进行利用，可被用来进行 Bypass ngx_lua构建的 SQL注入防御。
进阶测试
绕过姿势一：
参数大小写 + HPP
http://192.168.8.147/test/sql.aspx
?id=1 UNION/&ID=/SELECT null,name,null/&Id=/FROM master.dbo.sysdatabases
绕过姿势二：
GPC
在 ASPX 中，有一个比较特殊的 HPP 特性，当 GET/POST/COOKIE 同时提交的参数 id，服务端接收参数 id 的顺序 GET,POST,COOKIE，中间通过逗号链接，于是就有了这个 idea。
UNION、SELECT、FROM 三个关键字分别放在 GET/POST/COOKIE 的位置，通过 ASPX 的这个特性连起来，堪称完美的一个姿势，压根不好防。
但姿势利用太过于局限： 使用 Request.Params["id"] 来获取参数,GPC 获取到参数拼接起来，仅仅作为 Bypass 分享一种思路而已。
绕过姿势三：
uri 参数溢出
前面两种都是 MSSQL 的 Bypass，而且利用姿势还有一定的极限，有没有那么一种可以 Bypass Mysql，又可以 Bypass MSSQL，完全无视 SQL 注入防御，为所欲为的姿势呢？这就是接下来的终极大招了。
默认情况下，通过 ngx.req.get_uri_args、ngx.req.get_post_args 获取 uri 参数，只能获取前 100 个参数，当提交第 101 个参数时，uri 参数溢出，无法正确获取第 100 以后的参数值，基于 ngx_lua 开发的安全防护，无法对攻击者提交的第 100 个以后的参数进行有效安全检测，从而绕过安全防御。具体分析详见我写的另一篇文章：《打破基于 OpenResty 的 WEB 安全防护（CVE-2018-9230）》
Mysql Bypass 实例：
Mssql Bypass 实例：
这三种姿势主要利用 HPP，结合参数获取的特性和差异，从而绕过 ngx_lua_waf 的 SQL 注入防御。
不同语言、中间件、数据库，所对应的特性是有差异的，而这些差异在某些特定的场景下，是可以利用的。
添加评论