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"}
ヘッダー名の間に改行（\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 または\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"},
{"ヘッダー\t33", "Value33"}、
{"Header- 36", "Value36"},
{"Header-\t40", "Value40"},
{"Header 4a", "Value4a"},
{"Header\t 59", "Value59"},
{"Header\t 60", "Value60"}