Nginx 1.26 異動總覽
隨著 Nginx 1.26 的推出,我們也推出了幾項重要變更,以強化安全性並確保符合 HTTP 標準。以下是主要更新內容:
處理標頭名稱和值中的空白
為提升安全性,我們已強化遵循 RFC 7230 的規定,特別是針對標頭中空白字元的處理方式。如要進一步瞭解這些異動,請參閱附錄。
處理 Content-Length
和 Transfer-Encoding
標頭
在要求走私攻擊中使用的常見技巧之一,就是傳送含有 Content-Length
和 Transfer-Encoding
標頭的 HTTP 要求。雖然 Apigee Edge 已強化防禦這類攻擊,但 Nginx 現在會明確封鎖含有這兩個標頭的要求。如果傳送這類要求,Nginx 會回應 400 Bad Request 錯誤。
支援的加密方式
針對北向要求支援的加密法清單可能會隨著本版本變更。您可以查看路由器主機上 OpenSSL 支援的密碼編譯器,取得可用密碼編譯器的最新清單。
支援的金鑰大小
先前,系統預設會接受小於 2048 位元的 RSA、DSA 和 DH 金鑰,以及小於 224 位元的 ECC 金鑰。不過,這項更新將禁止在北向要求中,使用單向和雙向 TLS 連線的這類金鑰。
附錄
標頭中的空白
主要有三項變更:
- 先前允許的部分標頭名稱,現在已遭到 Nginx 1.26 禁止。含有這些標頭的要求會導致 400 Bad Request 錯誤。
- 先前允許的部分標頭值現在已遭到 Nginx 1.26 禁止。含有這些標頭的要求也會導致 400 Bad Request 錯誤。
- 先前由 Nginx 接受,但在訊息處理工具中造成下游失敗的部分標頭,現在會直接遭到 Nginx 拒絕。雖然這些標頭仍會導致 API 失敗,但 HTTP 失敗訊息會變更。
以下各節提供各種不允許的標頭名稱和標頭值範例。以下列舉幾個例子,但不一定涵蓋所有情況。建議您遵循 RFC 7230 的規範,設定標頭。
標頭名稱異動
本節列出在 Nginx 1.20.1 中允許使用的各種標頭名稱,但現在在 Nginx 1.26 中已禁止使用。
情境 | 標頭名稱範例 |
---|---|
標頭名稱開頭、結尾或中間的控制字元 | { '\u0001'Header0, Value0 } { Header6'\u0002', Value6 } { Header'\u0005'4, Value4 } |
標頭名稱開頭和結尾的空白字元 | {"Header2 ", "Value2"} {" Header3", "Value3"} {" Header4 ", "Value4"} |
標頭名稱開頭和結尾的 HTAB | {"\tHeader11", "Value11"} {"Header12\t", "Value12"} {"\tHeader13\t", "Value13"} |
標頭名稱中 HTAB、WS 的開頭和結尾組合 | {"\t Header24", "Value24"} {" \tHeader25", "Value25"} {"Header26 \t", "Value26"} {"Header27\t ", "Value27"} |
標頭名稱之間的 NewLine (\n) 後面緊接著 WS 或一連串 WS | {"Header\n 57Mutiline", "Value57"} {"Header\n 58Mutiline", "Value58"} |
標頭名稱之間的換行符號 (\n) 後面緊接 HTAB 或一系列 HTAB | {"Header\n\t73", "Value73"} {"Header\n\t\t74", "Value74"} |
標頭名稱之間的回車 (\r) 換行 (\n) 後面緊接 HTAB 或一系列 HTAB | {"Header\r\n\t69", "Value69"} {"Header\r\n\t\t70", "Value70"} |
標頭名稱之間的回車 (\r) 新行 (\n) 後面緊接 WS 或一系列 WS | {"Header\r\n 71", "Value71"} {"Header\r\n 72", "Value72"} |
標頭值變更
本節會顯示 Nginx 1.20.1 允許的各種標頭值,但在 Nginx 1.26 中不允許使用。
情境 | 範例 |
---|---|
允許在 HEADERVALUE 之間使用 \r\n 或 \r\n 與 WS 或 HTAB 的組合 |
{"Header47", "Value47\r\n MultiLine"}, {"Header48", "Value48\r\n MultiLine"}, {"Header49b", "Value49b\r\n \r\nMultiLine"}, {"Header50", "Value50 \r\n MultiLine"}, {"Header51", "Value51\r\n\tMultiLine"}, {"Header52", "Value52\r\n\t\tMultiLine"}, {"Header53", "Value53\t\r\n\tMultiLine"} |
允許在 HEADERVALUE 之間使用 \n 或 \n 與 WS 或 HTAB 的組合 |
{"Header61", "Value\n 61Multiline"}, {"Header62", "Value\n 63Multiline"}, {"Header65", "Value\n\t65"}, {"Header66", "Value\n\t\t66"}, {"Header67", "Value\n 67"}, {"Header68", "Value\n 68"} |
變更 HTTP 失敗回應
本節將說明舊版 Nginx 允許的標頭,但上游訊息處理器拒絕,導致傳回 400 狀態碼。不過,在 Nginx 1.26 中,這類標頭會直接在 Nginx 中導致失敗,導致要求無法轉送至訊息處理工具。
對於傳送這類標頭的用戶端,HTTP 狀態碼仍會維持 400。不過,由於失敗會由 Nginx 而非訊息處理器產生,因此 HTTP 回應主體可能會有所變動。
情境 | 範例 |
---|---|
在 HEADERNAME 之間插入 HTAB 或 WS 訊息處理器會拒絕這類要求。在 Nginx 1.26 中,Nginx 本身會拒絕這些要求。API 使用者會收到 400 錯誤回應,內文中會顯示 Nginx 錯誤訊息。 |
{"Header 5", "Value5"}, {"Header\t14", "Value14"}, {"Header\t 32", "Value32"}, {"Header \t33", "Value33"}, {"Header- 36", "Value36"}, {"Header-\t40", "Value40"}, {"Header 4a", "Value4a"}, {"Header\t 59", "Value59"}, {"Header\t 60", "Value60"} |