Apigee Edge 4.53.00 中的 Nginx 1.26 異動

Nginx 1.26 異動總覽

隨著 Nginx 1.26 的推出,我們也推出了幾項重要變更,以強化安全性並確保符合 HTTP 標準。以下是主要更新內容:

處理標頭名稱和值中的空白

為提升安全性,我們已強化遵循 RFC 7230 的規定,特別是針對標頭中空白字元的處理方式。如要進一步瞭解這些異動,請參閱附錄

處理 Content-LengthTransfer-Encoding 標頭

在要求走私攻擊中使用的常見技巧之一,就是傳送含有 Content-LengthTransfer-Encoding 標頭的 HTTP 要求。雖然 Apigee Edge 已強化防禦這類攻擊,但 Nginx 現在會明確封鎖含有這兩個標頭的要求。如果傳送這類要求,Nginx 會回應 400 Bad Request 錯誤。

支援的加密方式

針對北向要求支援的加密法清單可能會隨著本版本變更。您可以查看路由器主機上 OpenSSL 支援的密碼編譯器,取得可用密碼編譯器的最新清單。

支援的金鑰大小

先前,系統預設會接受小於 2048 位元的 RSA、DSA 和 DH 金鑰,以及小於 224 位元的 ECC 金鑰。不過,這項更新將禁止在北向要求中,使用單向和雙向 TLS 連線的這類金鑰。

附錄

標頭中的空白

主要有三項變更:

  1. 先前允許的部分標頭名稱,現在已遭到 Nginx 1.26 禁止。含有這些標頭的要求會導致 400 Bad Request 錯誤。
  2. 先前允許的部分標頭值現在已遭到 Nginx 1.26 禁止。含有這些標頭的要求也會導致 400 Bad Request 錯誤。
  3. 先前由 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"}