マイクロサービスの非同期：クラウド環境における最新のHTTPリクエスト隠し技 ⚡

マイクロサービスの非同期：クラウド環境における最新のHTTPリクエスト隠し技 ⚡

==============================================================================

クラウドネイティブアーキテクチャの現代において、単一のHTTPリクエストの流れはほとんど一直線ではありません。アプリケーションコードに到達する前に、リクエストはさまざまなインフラを通過します：Global CDN、Cloud Load Balancer（例：AWS ALB）、Web Application Firewall（WAF）、Ingress Controller（NGINX）、そしておそらくSidecar Proxy（Envoy）を含むService Mesh。

この「信頼の連鎖」は、ウェブセキュリティ上最も破壊的な脆弱性の一つであるHTTP Request Smuggling (HRS)、特に最新のMicroservice Desyncの温床となっています。

Microservice Desyncとは？

---

基本的に、デシンクはリクエストチェーン内の二つの異なるサーバーがリクエストの終了位置と次のリクエストの開始位置について意見が一致しないときに発生します。

モノリシック環境ではこれは稀な見落としでしたが、マイクロサービス環境では—異なるチームが異なる言語（Go、Node.js、Python）や異なるプロキシ（Nginx、HAProxy、Envoy）を使用している場合—パースミスマッチの確率は飛躍的に増加します。

攻撃者がリクエストを「隠し持つ」ことに成功すると、フロントエンドとバックエンド間の永続TCP接続を汚染します。次にその接続を使って正規のユーザーがリクエストを送ると、そのリクエストは攻撃者の隠しデータで先頭に付加されてしまいます。

メカニズム：デシンクの「物理学」

---

デシンクがどう起きるか理解するには、HTTP/1.1がリクエスト長を決定する二つの主要な方法を見る必要があります：

1. Content-Length (CL): リクエストボディの総バイト数を表す単純な整数。

2. Transfer-Encoding: chunked (TE): ボディを「チャンク」に分けて送る方法。各チャンクは16進数のサイズとデータからなり、最後は0バイトのチャンクで終了。

伝統的な対立（CL.TEとTE.CL）

• CL.TE: フロントエンドはContent-Lengthを使いますが、バックエンドはTransfer-Encodingを使います。攻撃者が両方を送ると、フロントエンドはリクエスト全体を処理しますが、バックエンドは0チャンクで停止し、残りのデータはバッファに「ぶら下がる」状態になります。

• TE.CL: 逆です。フロントエンドはチャンクを処理しますが、バックエンドはContent-Lengthで指定されたバイト数だけを読み取ります。

現代の変種：HTTP/2ダウングレード（H2.CLとH2.TE）

業界の動きはHTTP/2 (H2)へと進み、リクエスト隠し技を排除しようとしました。H2はバイナリプロトコルで長さフィールドが組み込まれていますが、多くのバックエンドは依然としてHTTP/1.1を使用しています。これにより、“H2ダウングレード”がエッジで必要となります。

フロントエンドのプロキシ（例：Nginx）がH2リクエストを受け取り、それをバックエンド向けにH1.1リクエストに変換する場合、Content-LengthやTransfer-Encodingヘッダーを合成する必要があります。攻撃者が禁止されたヘッダー（例：隠しTransfer-Encoding）をH2層を通じて忍び込ませると、結果として得られるH1.1リクエストは曖昧になり、古典的なデシンクが再発します。

マイクロサービスが悪化させる理由

---

マイクロサービスアーキテクチャでは、“意見の不一致の攻撃面”が非常に大きくなります。

1. プロキシチェーンの複雑さ

リクエストの流れを想像してください：Cloudflare（CDN）→ AWS ALB（LB）→ NGINX（Ingress）→ Envoy（Sidecar）→ Node.js（マイクロサービス）

これらすべてのコンポーネントがHTTPヘッダーを同じように解釈しなければなりません。例えば、NGINXがヘッダー名の後にスペースを許す（Transfer-Encoding : chunked）一方で、Envoyが許さない場合、デシンクが生まれます。

2. Sidecarの脆弱性

IstioのようなサービスメッシュはEnvoyサイドカーを使用します。最近の研究（例：CVE-2024-23326）では、Envoyのような洗練されたプロキシも、ヘッダーを厳密にサニタイズしないと”リクエストトンネリング”に騙される可能性があることが示されています。

3. 言語固有の癖

異なるバックエンドランタイムは、HTTPの誤った形式に対して異なる「寛容度」を持っています：

• Node.jsはCRLFの行末に厳しい場合があります。

• Go (net/http)は特定のバージョンでLFだけを行末として受け入れることがあります（例：CVE-2025-22871）。

攻撃者は、厳格なプロキシには一つのメッセージに見えるリクエストを、寛容なバックエンドには二つのメッセージとして解釈させることが可能です。

重要な悪用シナリオ

---

1. WAFと認証の回避

WAFは通常、エッジでリクエストを検査し、悪意のあるパターンを検出します。攻撃者が正規のリクエストに隠し持ったリクエストを仕込むと、WAFは外側のシェルだけを見ます。

例：ペイロード:

Plain textANTLR4BashCC#CSSCoffeeScriptCMakeDartDjangoDockerEJSErlangGitGoGraphQLGroovyHTMLJavaJavaScriptJSONJSXKotlinLaTeXLessLuaMakefileMarkdownMATLABMarkupObjective-CPerlPHPPowerShell.propertiesProtocol BuffersPythonRRubySass (Sass)Sass (Scss)SchemeSQLShellSwiftSVGTSXTypeScriptWebAssemblyYAMLXML

WAFはPOST /public-apiを通過させますが、バックエンドは二つのリクエスト：公開用と隠しリクエスト（例：/admin/delete-user）を認識します。

2. ユーザーセッションの乗っ取り（”Piggyback”）

これは最も”静か”で危険なバリアントです。攻撃者は部分的なリクエストを隠し持ち、被害者を待ちます。

• 攻撃者の送信内容： POST /log-comment HTTP/1.1で始まる隠しリクエストだが、ボディの最後の部分は含まれていません。

• 被害者の送信： /dashboardへの正規リクエストとともに、敏感なSession-Cookieを含む。

• 結果： バックエンドは被害者のリクエストを攻撃者の隠しPOSTに先頭付加します。被害者のSession-Cookieは攻撃者のコメントの本文となり、後でコメントを読むことでクッキーを盗めます。

3. キャッシュポイズニング

CDNやキャッシングプロキシが関与している場合、攻撃者はエラー（例：404）や悪意のリダイレクトを引き起こすリクエストを隠し持つことができます。もしそのレスポンスが正規のURL（例：index.html）にマッピングされると、その後のユーザーは”毒された”エラーやリダイレクトをキャッシュから受け取ることになります。

デシンクの検出：タイミングが全て

---

HRSの検出は非常に難しく、標準のログには何も記録されないことが多いです。セキュリティチームは通常タイミングベースのプロービングを用います。

• CL.TEプロービング: Content-Lengthを実際に送るデータより少し長めに設定し、フロントエンドがCLを使う場合、残りのバイトを待つために明らかな遅延（10〜30秒）が発生し、504 Gateway Timeoutを返します。

• TE.CLプロービング: 不正なチャンクリクエストを送信し、バックエンドが混乱すると次のチャンク（存在しない）を解析しようとしてハングします。

2026年の防御戦略：クラウドの堅牢化

---

2026年には、WAFだけに頼るのは不十分です。プロトコルの対称性を徹底する必要があります。

1. HTTP/2またはHTTP/3をエンドツーエンドで強制

最も効果的な防御策は、「ダウングレード」を排除することです。フロントエンドがH2をクライアントとバックエンドのマイクロサービス間で使用すれば、CLとTEの曖昧さは解消されます。

2. 厳格なヘッダー正規化

エッジプロキシ（NGINX、Envoy、HAProxy）は、曖昧なリクエストを拒否するよう設定し、「修正」しようとしないことが重要です。

• NGINX: underscores_in_headers off;を設定し、RFC準拠のモジュールを使用します。

• Envoy: v3.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager.common_http_protocol_optionsで厳格なヘッダー検証を設定します。

3. 接続の再利用を無効化（核オプション）

攻撃の兆候がある場合、プロキシとバックエンド間の「Keep-Alive」や永続接続を無効にできます。これにより、すべてのリクエストが新しいTCP接続を使用し、隠しリクエストによる「毒化」が次のユーザーに波及しなくなります。

注意： パフォーマンスに大きな影響を与えます。

4. アプリケーション層のゼロトラスト

X-Forwarded-ForやX-Internal-Authといったヘッダーを盲信しないこと。各マイクロサービスは、フロントエンドプロキシの”境界”セキュリティに頼るのではなく、JWT（JSON Web Token）を独立して検証すべきです。

結論

---

マイクロサービスの非同期は、複雑なシステムにおいて”ギャップ”がコンポーネントと同じくらい危険であることを思い出させてくれます。プロキシやサイドカーを層として重ねるほど、厳格で標準化されたプロトコルのパースが生存のために必要となります。

“寛容”なバックエンドの時代は終わりました。現代のクラウド環境を守るためには、プロトコルの対称性—すなわち、チェーン内のすべてのホップがリクエストを正確に同じ方法で解釈する未来へと進む必要があります。