Apigee Edge 4.53.01 での 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 で受け入れられていたものの、メッセージ プロセッサのダウンストリームで障害を引き起こしていた一部のヘッダーが、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"}
ヘッダー名の直後に WS または一連の WS が続く NewLine（\n） {"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"}
ヘッダー名の直後に WS または一連の WS が続く改行（\r）改行（\n） {"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 では許可されていたが、アップストリームの Message Processor では拒否され、400 ステータス コードが返されたヘッダーについて説明します。ただし、Nginx 1.26 では、このようなヘッダーは Nginx で直接エラーを引き起こし、リクエストが Message Processor に転送されなくなります。

このようなヘッダーを送信するクライアントの場合、HTTP ステータス コードは 400 のままになります。ただし、エラーがメッセージ プロセッサではなく 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"}