Apigee Edge 4.53.00 の Nginx 1.26 の変更

Nginx 1.26 の変更の概要

Nginx 1.26 のリリースでは、セキュリティを強化し、HTTP 標準に準拠するために、いくつかの重要な変更が導入されています。主な更新内容は次のとおりです。

ヘッダー名と値の空白文字の処理

セキュリティを強化するため、特にヘッダー内の空白文字の処理に関して、RFC 7230 への準拠が強化されました。これらの変更について詳しくは、付録をご覧ください。

Content-Length ヘッダーと Transfer-Encoding ヘッダーの処理

リクエスト スマグリング攻撃で使用される一般的な手法の 1 つは、Content-Length ヘッダーと Transfer-Encoding ヘッダーの両方を含む HTTP リクエストを送信することです。Apigee Edge はすでにこのような攻撃に対して強化されていますが、Nginx では両方のヘッダーを含むリクエストが明示的にブロックされるようになりました。このようなリクエストが送信されると、Nginx は 400 Bad Request エラーで応答します。

サポートされている暗号

ノースバウンド リクエストでサポートされている暗号のリストは、このリリースで変更される可能性があります。ルーターのホストで OpenSSL でサポートされている暗号を確認して、使用可能な暗号の最新リストを取得できます。

サポートされている鍵のサイズ

以前は、2,048 ビット未満の RSA、DSA、DH 鍵と、224 ビット未満の ECC 鍵がデフォルトで受け入れられていました。ただし、この更新により、そのような鍵は、ノースバウンド リクエストの単方向 TLS 接続と双方向 TLS 接続の両方で許可されなくなります。

付録

ヘッダー内の空白文字

主な変更点は次の 3 つです。

  1. 以前は許可されていた特定のヘッダー名は、Nginx 1.26 で許可されなくなりました。これらのヘッダーを含むリクエストは、400 Bad Request エラーになります。
  2. 以前は許可されていた特定のヘッダー値は、Nginx 1.26 では許可されなくなりました。これらのヘッダーを含むリクエストでも、400 Bad Request エラーが発生します。
  3. 以前は Nginx で受け入れられていたものの、Message Processor のダウンストリームで障害を引き起こしていた一部のヘッダーは、現在 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"}
{"Header\n 58Mutiline", "Value58"}
ヘッダー名の間に改行 (\n) があり、その後に HTAB または一連の HTAB が続く {"Header\n\t73", "Value73"}
{"Header\n\t\t74", "Value74"}
ヘッダー名の間に改行 (\r) または連続したタブ文字が続く場合 {"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 または \r\n と WS または HTAB の組み合わせが 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"}
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 では許可されていたが、アップストリームの Message Processor によって拒否され、400 ステータス コードが返されたヘッダーについて説明します。ただし、Nginx 1.26 では、このようなヘッダーが Nginx で直接失敗し、リクエストが Message Processor に転送されなくなります。

このようなヘッダーを送信するクライアントの場合、HTTP ステータス コードは 400 のままになります。ただし、エラーは Message Processor ではなく Nginx によって生成されるため、HTTP レスポンスの本文が変更される可能性があります。

シナリオ 例
HEADERNAME の間に HTAB または WS が挿入されている

Message Processor はこのようなリクエストを拒否します。Nginx 1.26 では、このようなリクエストは Nginx 自体によって拒否されます。API コンシューマは、本文に Nginx エラー メッセージを含む 400 エラー レスポンスを受け取ります。

 {"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"}