やあ、お疲れ。最近、いくつかの案件でコードレビューを回していて、相変わらず根絶やしにできていない厄介なヤツを見つけたんだ。それが「Open Redirect（オープンリダイレクト）脆弱性」だ。
開発者の中には、「単にユーザーを別のページに飛ばすだけだろ？何がそんなに危険なんだよ」と甘く見ている連中が少なからずいる。だが、レッドチームの視点から言わせてもらえば、こいつは「フィッシング詐欺の踏み台」として最高にキレる極悪な導火線になる。ユーザーが信頼している正規のドメイン（お前の会社のブランド名だ）を経由して、一瞬で偽のログイン画面に飛ばされたらどうなる？ セキュリティ意識の高いユーザーですら、完全に油断してクレデンシャルを入力してしまう。
今回は、このオープンリダイレクトがなぜ現場で凶悪な武器になるのか、そのメカニズムと、二度と実装ミスを起させないための「完全防御コード＆インフラ設定」を叩き込んでおく。手を動かす準備をしておけ。
—
1. 攻撃者が狙う盲点：なぜオープンリダイレクトは放置されるのか？
Webアプリケーションを作っていると、「ログイン成功後に元のページに戻す」「外部サイトへのリンクを踏んだ際に『外部サイトへ移動します』というクッションページを挟む」といった要件は山ほど出てくる。
ここで開発者がよくやる実装ミスが、次のような丸投げコードだ。
// 最悪な実装例：GETパラメータをそのままリダイレクト先として信用している
$redirect_url = $_GET['url'];
header("Location: " . $redirect_url);
exit;一見すると便利そうだが、攻撃者はここに次のようなリクエストを仕掛ける。
https://example.com/login.php?url=https://evil.com/phishing
example.com という、誰もが信頼するドメインから発行されたレスポンスなのに、ブラウザはそのまま evil.com へ直行する。メールやSNSでこのURLをばら撒かれたとき、URLのドメイン部分だけを確認したユーザーは、まさか自分が罠にハマっているとは夢にも思わない。これがオープンリダイレクトの恐ろしさだ。単体では致命的なRCE（リモートコード実行）やSQLiほど派手ではないが、ソーシャルエンジニアリングの成功率を跳ね上げる最強の相棒なのだ。
—
2. 脆弱なホワイトリスト方式という「罠」
「おいおい、うちではちゃんとホワイトリストで弾いてるぜ」と胸を張るエンジニアもいる。だが、そのホワイトリスト、本当に正しく実装されているか？
よくあるダメなホワイトリストの例を見てみよう。
// やりがちな「ガバガバ」ホワイトリストチェック
$redirect_url = $_GET['url'];
// 「example.com」が含まれていれば許可する、という甘い判定
if (strpos($redirect_url, 'example.com') !== false) {
header("Location: " . $redirect_url);
exit;
}この実装、攻撃者からすれば「どうぞハックしてください」と言っているようなものだ。
次のようなURLを渡されたらどうなる？
https://example.com/login.php?url=https://example.com.evil.com/phishing
strpos は文字列の中に example.com が含まれているかを見るだけだから、この攻撃用URLはやすやすとすり抜けてしまう。正規表現の雑な実装や、パース処理の不備をついたバイパス手法は、レッドチームの常套手段だ。ホワイトリストを自前で実装するのは、フラグの立て忘れやエッジケースの考慮漏れを生むリスクが高すぎる。
—
3. 【完全防御】実務で使えるセキュアな実装と代替案
では、どうやってこのリスクを完全に潰すべきか。
原則はシンプルだ。「外部への動的なリダイレクトは極力避ける。どうしてもやるなら、URL全体ではなく『キー（ID）』ベースで管理するか、厳密なURLパースを行うこと」。
現場で即座に使える、安全なPHPの実装サンプルを置いておく。コピペしてチームに共有してくれ。
PHPによるセキュアなリダイレクト処理のサンプル
<?php
/**
* 安全なリダイレクト処理の関数
* @param string $input_url ユーザーから渡されたリダイレクト先キーまたはパス
*/
function safe_redirect($input_url) {
// 1. 外部の完全なURL（http:// や https:// で始まるもの）は原則として直接受け付けない
// 代わりに、許可された内部パスのホワイトリスト、または「マッピングID」を使用する
$allowed_paths = [
'dashboard' => '/user/dashboard.php',
'profile' => '/user/profile.php',
'settings' => '/user/settings.php'
];
// パターンA: キー指定方式（最も安全。URLパラメータには 'dashboard' などのキーだけを渡させる）
if (array_key_exists($input_url, $allowed_paths)) {
header("Location: " . $allowed_paths[$input_url]);
exit;
}
// パターンB: 同一ドメイン内（相対パス）のみを厳密に許可する場合
// parse_url() を使ってスキームやホストが空、または自社ドメインであることを強制する
$parsed = parse_url($input_url);
// スキーム（http/https）やホスト（domain.com）が指定されているものは外部遷移とみなして拒否
if (isset($parsed['scheme']) || isset($parsed['host'])) {
// ログに不正なリダイレクト試行を記録
error_log("不審な外部リダイレクト試行をブロックしました: " . $input_url);
// フォールバックとしてデフォルトの安全なページへ飛ばす
header("Location: /index.php");
exit;
}
// 先頭がスラッシュ1つで始まり、スラッシュ2つ（//）で始まらないことを確認（プロトコル相対URL対策）
if (strpos($input_url, '/') === 0 && strpos($input_url, '//') !== 0) {
header("Location: " . $input_url);
exit;
}
// どの条件にも合致しない場合はデフォルトへ
header("Location: /index.php");
exit;
}
// 実行例
// ユーザーからの入力を受け取る（実際には$_GET['redirect']など）
$user_input = $_GET['redirect'] ?? 'dashboard';
safe_redirect($user_input);
?>このコードのポイント
1. キー方式（パターンA）の推奨: ユーザーに ?url=https://... と入力させるのではなく、?redirect=dashboard のように内部のルーティング定義と紐づいたキーを渡させるのが、最も確実で安全な設計だ。
2. プロトコル相対URL（//evil.com）の排除: 開発者がよく見落とすのが、// で始まるURLだ。これがあると、ブラウザは現在のスキームを引き継いで外部サイトへ飛んでしまう。厳密なチェックでこれを弾いている。
3. parse_url() の活用: URLの構造を分解し、意図しないホスト名が含まれていないかを厳密に検証する。
—
4. アプリケーション層だけに頼らない、インフラ・WAFでの多層防御
セキュリティの鉄則は「単一障害点の排除」だ。アプリケーションのコードレビューで防ぎきれなかったとしても、リバースプロキシやWAF（Web Application Firewall）のレイヤーで不審な挙動を検知・ブロックできるようにしておくべきだ。
例えば、Nginx環境であれば、リクエストパラメータに含まれる怪しいURLパターンをあらかじめ制限、あるいはログを監視する設定を入れることができる。また、モダンなクラウドWAF（AWS WAFやCloudflareなど）を使用している場合は、オープンリダイレクトを狙った既知の攻撃シグネチャを有効化しておくだけで、大半の自動スキャナーによる攻撃を防ぐことができる。
だが、WAFはあくまで「最後の安全網」であって、根本的な解決策（セキュアコーディング）の代わりにはならない。そこをきっちり履き違えないようにしてほしい。
—
5. チーフからのまとめ
オープンリダイレクトは、その地味な名前とは裏腹に、企業のブランド信頼度を一夜にして地に落とすフィッシング攻撃の強力なトリガーになり得る。
「URLをそのままリダイレクトに渡さない」
「外部URLを受け渡す必要性そのものを疑う」
「どうしてもやるならキー管理か厳密なパースを行う」
この基本ルールを、今日からお前のチームのコーディング規準に必ずブッ込んでおいてくれ。インシデントが起きてから「知らなかった」では済まされないからな。さて、次の脆弱性潰しにかかるとしようか。頼んだぞ。
コメント