Apigee Edge 4.53.00 中的 Nginx 1.26 異動

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 連線的這類金鑰。

附錄

標頭中的空白

有三項主要變更：

  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"}
標頭名稱之間的換行符號 (\n) 後面緊接著 WS 或一連串 WS {"Header\n 57Mutiline", "Value57"}
{"標頭\n 58Mutiline", "Value58"}
標頭名稱之間的換行符號 (\n) 後面緊接著 HTAB 或一系列 HTAB {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
標頭名稱之間的回車 (\r) NewLine (\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 中不允許使用。

情境 範例
\r\n 或以 WS 或 HTAB 搭配的\r\n 或任意選項，可在 HEADERVALUE 之間使用 {"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"}
\n 或 與 WS 或 HTAB 的組合，兩者之間可在 HEADERVALUE 之間使用 {"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"}