HTTPパラメータ汚染（HPP）：その「解釈のズレ」が脆弱性の深淵となる
セキュリティの世界に身を置いていると、「通信の正規化」という言葉がいかに重いかを痛感する場面に何度も遭遇する。多くのエンジニアは「WAFを通しているから安全だ」と安易に信じ込むが、WAFは万能の盾ではない。それはあくまで、プロトコルの解釈レイヤーにおける「翻訳機」に過ぎないからだ。
今回深掘りするのは、HTTPパラメータ汚染（HPP: HTTP Parameter Pollution）。これは単なる入力値の検証不備ではなく、「Webサーバーとアプリケーションフレームワークが、複雑なHTTPリクエストをどう解釈するか」という、実装の『非対称性』を突く攻撃である。
なぜHPPは脆弱性の「盲点」なのか
HTTP仕様（RFC 7230など）において、重複するパラメータの扱いは必ずしも厳密に定義されていない。例えば、?id=1&id=2 というリクエストが来たとき、以下の挙動の違いがセキュリティの穴を生む。
- Node.js (Express): 最初の値をとるか、配列として処理するか（ミドルウェア依存）
- ASP.NET: カンマ区切りで連結する (
1,2) - PHP/Apache: 最後の値を優先する (
2)
攻撃者はこの挙動の差異を利用する。WAFが最初のパラメータ（id=1）を見て「これは安全な値だ」と判定し通過させたとしても、バックエンドのPHPが後ろのパラメータ（id=admin）を優先して処理すれば、WAFは完全にバイパスされる。これは、パケットの構造レベルで「WAFが認識する論理」と「バックエンドが実行する論理」に断絶があるからだ。
攻撃のメカニズム：防御層をすり抜ける「二重解釈」
例えば、以下のSQLインジェクションを狙ったリクエストを考えてほしい。
GET /search?id=1&id=SELECT++FROM+users– HTTP/1.1
Host: secure-app.com
WAFは最初の id=1 を見て「正当なクエリ」と判断する。しかし、バックエンドがパラメータを連結して処理する実装になっていた場合、クエリは SELECT FROM users-- として解釈される。あるいは、WAFが「SELECT」という文字列をブロックしていても、id=1&id=UNION... のように分割して送り込まれると、正規化エンジンがそれを単一の文字列として再構成できず、チェックをすり抜けることがある。
現場で戦うための「アーキテクチャ防衛」
この問題に対する特効薬は存在しない。あるのは「多層防御」という泥臭い積み重ねだけだ。
1. WAFとバックエンドのパラメータ解釈を強制的に統一する
WAFの正規化設定において、「重複パラメータの扱いは必ず最初のもの（または最後のもの）のみを採用する」というポリシーを厳格に適用せよ。例えば、Nginx (ModSecurity) を用いる場合は、以下のように重複パラメータを排除する設定を注入する。
ModSecurity設定例: 重複パラメータを検知して拒否する
SecRule ARGS_NAMES “@inspectFile” “id:10001,phase:2,deny,status:400,msg:’HPP detected: Duplicate parameters'”
もしくは、パラメータを最初の値のみに強制正規化する（環境による）
重要なのは、WAFで処理した後の値をバックエンドに渡す際に「単一」であることを保証すること
2. アプリケーションコード側での「厳格なバインド」
フレームワーク任せのパラメータ取得は危険だ。可能な限り、型定義されたDTO（Data Transfer Object）を使用し、単一の値しか受け取らない設計にする。
// Node.js (Express) での脆弱な実装例
const id = req.query.id; // これだと、攻撃者が配列を送った場合に意図しない挙動をとる可能性がある
// 修正案：厳格な型チェックとバリデーション
const id = Array.isArray(req.query.id) ? req.query.id[0] : req.query.id;
if (!/^\d+$/.test(id)) {
throw new Error(“Invalid parameter format”); // 数値以外は即座に拒絶
}
次世代の脅威：AIとプロンプトインジェクションへの応用
HPPの本質は「解釈の多義性」だ。これは、現代の生成AI（LLM）アプリケーションにおけるプロンプトインジェクションにもそのまま当てはまる。
AIに対するプロンプト（指示）と、ユーザーからの入力を混在させ、ガードレイル（入力フィルタ）がAIのコンテキスト理解とズレている場合、AIは攻撃者の意図するプロンプトを「実行すべき指示」として解釈してしまう。
これを防ぐには、「トークン化レベルでの分離」が必要だ。ユーザー入力を単なる文字列としてではなく、特殊なデリミタで囲う、あるいはプロンプトのコンテキストと入力を物理的に異なるデータ構造として分離するアーキテクチャが求められる。
結びに：セキュリティのプロとして
HPPを理解することは、Webサーバーの底流にあるプロトコルの挙動を理解することに他ならない。セキュリティバイブルを読んでいる諸君には、単にツールを導入して満足するのではなく、「パケットが入り口から出口まで、どう変容してサーバーに到達するのか」というデータのライフサイクルを常に想像してほしい。
脆弱性は、設定ミスというよりも「設計の隙間」に潜んでいる。その隙間を埋めるのは、最新のAI防衛ツールではなく、エンジニアである君たちの深い洞察力だ。次回のコードレビューでは、Request.QueryString や req.params がどう処理されているか、その「解釈の余地」に目を光らせてみてほしい。
コメント