URLバリデーション回避チートシート登場：SSRFやCORS誤設定を生む“あいまいなURL”の落とし穴

概要

本記事の元ソースは、PortSwigger Researchによる「Introducing the URL validation bypass cheat sheet」です。URLの入力チェック（URLバリデーション）をすり抜ける“回避”が、SSRF（Server-Side Request Forgery）、CORS設定ミス、オープンリダイレクトなど多数の脆弱性の根本要因になっている、という問題提起を出発点に、回避の発生メカニズムと対策の方向性を整理します。

URLバリデーションが難しい主因は、アプリが「文字列としてのURL」を見て判断しているのに対し、実際にリクエストを行うコンポーネント（HTTPクライアント、リバースプロキシ、ブラウザ、ミドルウェア、ライブラリ等）が「別のルールでURLを解釈」してしまう点にあります。入力チェックで許可したつもりの宛先が、最終的な解釈・正規化・リダイレクト追従・DNS解決などの過程を経て、意図しないホストやスキームに到達する——このギャップが、回避の温床になります。

詳細

PortSwiggerのチートシートは、URLが「あいまいに解釈される」局面を軸に、どのような条件で検証が破られやすいかを整理するための実務的な参照点です。たとえばSSRFでは、サーバが外部URLへアクセスできる機能（画像取得、Webhook、URLプレビュー、PDF生成、SSO連携など）が攻撃面になります。ここでの失敗は、単に“禁止ホストを弾く”だけでは不十分で、(1) どの段階の値を検証しているか、(2) 解釈が変化するポイントがどこにあるか、(3) 実際の接続先をどう確定し担保するか、という設計問題になります。

CORSやオープンリダイレクトでも同様です。CORSでは「信頼できるオリジン」を判定するロジックが、部分一致や不完全な正規化、複数表現（大小文字、末尾ドット、ポート、省略表現等）を想定しない実装だと、意図しないオリジンを許可してしまいます。オープンリダイレクトでは、遷移先URLを“安全”と見なしてしまうことで、フィッシングや認可コード窃取の足がかりになり得ます。つまり、URL検証は「表面上の一致」ではなく「意味（最終的に到達する場所）の一致」を扱う必要があります。

では実装側は何をすべきでしょうか。チートシートが示唆するのは、“バイパス文字列”を個別にブラックリスト化する発想ではなく、検証対象と実行系の差分を減らすアプローチです。具体的には、URLを受け取ったら一度パースして要素（スキーム、ホスト、ポート、パス等）に分解し、許可ポリシーを要素レベルで適用します。さらに、DNS解決やリダイレクト追従の結果が変化し得ることを前提に、最終的な接続先（解決後IP、実接続先ホスト、最終URL）を基準に再検証する設計が重要になります。ネットワーク境界（Egress制御、プロキシ、到達可能先の分離）で技術的に“行けない”状態を作ることも、URLバリデーションの限界を補う現実的な対策です。

また、周辺ツールの活用も現場では有効です。PortSwiggerのBApp（拡張）として、CORSの誤設定や信頼ドメイン判定の問題に焦点を当てたスキャナが紹介されており、研究やチートシートで整理された観点をテストに落とし込む流れが示されています。こうした資料は、開発者が実装を固めるだけでなく、セキュリティレビューやペネトレーションテストで「何を確認すべきか」を共通言語化するのにも役立ちます。

最後に、URLバリデーション回避の話題は、SQLiのフィルタ回避と同様に“フィルタ依存の防御が破られやすい”という一般則とも接続します。入力を単純な禁止リストで裁くほど、仕様の複雑さ・表現の多様性・処理系差分の前に脆くなります。重要なのは、許可の定義を狭く明確にし、正規化と実行結果に基づく検証を組み合わせ、加えてネットワークや権限で被害半径を最小化することです。チートシートは、その検討を始めるための地図として位置づけるのがよいでしょう。