为什么 modsecurity 在 POST 请求中需要 Content-Length？

Question

我有一个 RESTful Web 服务，它接受对没有实体主体的资源的 POST 请求，例如空的 POST 请求。默认的 modsecurity 配置要求所有 POST 请求都具有 Content-Length：

# Require Content-Length to be provided with every POST request
SecFilterSelective REQUEST_METHOD "^POST$" chain
SecFilterSelective HTTP_Content-Length "^$"

modsecurity 控制台将此报告为 PROTOCOL_VIOLATION/EVASION。但是，在阅读HTTP/1.1 RFC 时，我不认为这是真的。允许服务器要求 Content-Length（返回 400 或 411），但我看不到任何内容表明服务器必须（或建议它应该）以这种方式运行。

这可能因浏览器而异，但在没有实体主体的情况下发出 POST 请求的 Flash 客户端不会发送请求标头。当你做'curl -XPOST ...'时也不会卷曲。由于这些原因，并且因为我认为 modsecurity 规则是对 HTTP 规范的误解，我正在考虑在我们的配置中取消对 POST 请求的 Content-Length 标头的要求。

有谁知道是否有特定的漏洞利用此规则来解决？大量的谷歌搜索，我只发现这是库存 modsecurity 配置的一部分。

Answer 1

首先，您应该知道您正在运行一个过时版本的 ModSecurity（分支 1.x）。如果您运行的是 Apache 2.0.x，您应该升级到 ModSecurity 2.x。如果您仍在运行 Apache 1.3.x，那么恐怕您别无选择，因为 ModSecurity 2.x 无法使用它。ModSecurity 1.x 本身并不容易受到攻击，但它的规则引擎对于当今的需求来说太不灵活了。

如果我没记错的话，ModSecurity 1.x 要求 POST 请求指定内容长度纯粹是因为它不支持分块请求正文（提交请求正文的另一种方式，其中总长度直到最后才知道）。分块请求正文在当时非常罕见（我们说的是 2003 年、2004 年）并且仍然很少见（尽管一些移动设备正在使用它们）。

ModSecurity 2.x 中没有这样的限制。

如果您删除该规则，您将创建一个大漏洞，有人可以通过该漏洞潜入未被发现的攻击。另一方面，我可以争辩说，在您运行 ModSecurity 1.x 的情况下，还有其他方法可以做到这一点。或者，调整规则以拒绝设置了 Transfer-Encoding 请求标头的请求。你应该是安全的。

披露：我写了 ModSecurity。