為什麼 modsecurity 在 POST 請求中需要 Content-Length？
我有一個 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 …”時，curl 也不會。由於這些原因，並且因為我認為 modsecurity 規則是對 HTTP 規範的誤解，我正在考慮在我們的配置中取消對 POST 請求的 Content-Length 標頭的要求。
有誰知道這個規則是否存在特定的漏洞被創建來解決？許多Google搜尋，我只發現這是股票 modsecurity 配置的一部分。
首先，您應該知道您正在執行一個過時的 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。