なぜ危ないのか
社外レビュー用のURLが取引先の社内メールで共有されると、そのメール環境が第三者に覗かれていた場合、オープンリダイレクトを悪用したフィッシングURLが作られるリスクがある。「信頼できる送り元のURLだから大丈夫」という判断を誘発するために、攻撃者はあえて正規ドメインのURLを使う。
AIが生成したHTMLはレビュアーが表示を確認する目的で使われるため、スクリプトの動作まで精査されにくい。レビュアーは見た目やテキスト内容に集中しており、URLパラメータを操作してリダイレクトが発生するかどうかを試す人はほぼいない。そのため送り手側がオープンリダイレクトを事前に検出する責任を持つ必要がある。
レビュー終了後もURLが有効なまま放置されるケースが多く、オープンリダイレクトを含むHTMLが長期間にわたって悪用可能な状態になる。共有URLの有効期限を設定していない場合は、半年後・一年後でも同じURLが機能し続け、攻撃の機会が拡大する一方だ。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
ソースで見る場所
HTMLファイルをVSCodeで開き、Ctrl+Fで`location.href`を検索する。ヒットした行に`=`が続き、右辺が文字列リテラルではなく変数や式の場合は詳しく確認する。同じファイルでその変数がURLSearchParamsから取得されている場合はオープンリダイレクトの可能性が高い。
次にformタグを全件確認する。`<form action=`の後が変数展開になっている場合や、JavaScriptでformのactionを書き換えている場合はリダイレクト先が制御できていない可能性がある。静的なパスが書かれている場合は問題ないが、`document.querySelector('form').action = someVar`のような行があれば要チェックだ。
ブラウザでHTMLを開いてURLバーの末尾に`?redirect=https://example.com&next=https://example.com`を手動で追加し、そのまま読み込む。ページが`example.com`に遷移した場合はオープンリダイレクトが確認された。遷移しない場合でもコードを目視で確認し、意図した防御処理があることを確かめる。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
安全に共有する設定
オープンリダイレクトがないと確認できたHTMLを共有する場合でも、URL自体には認証を付けることを推奨する。ギガサイト便であれば、ファイルをアップロードした後にパスワードや会社ドメイン認証を設定してURLを発行できる。レビュアー以外がアクセスできない状態を作ることで、万が一の見落としによる被害範囲を限定できる。
URLを送るメールやSlackのメッセージに、URLの有効期限を明記する。「〇月〇日23:59まで有効」と書いておけば、レビュー終了後に失効させるリマインダーにもなり、URLが長期間公開状態になるリスクを防げる。ギガサイト便なら期限付きで発行できるため、この管理が自動化される。
チェック完了後にメールやSlackで共有する前に、チェックリストのすべての項目に問題なしと記録しておく。スクリーンショットやテキストで記録を残しておくと、後から「あのHTMLは確認したか」と問われたときに証跡を示せる。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
再発防止ルール
社外レビュー用HTMLを生成する際のAIプロンプトテンプレートに、「URLパラメータをlocation.href・window.location・form.actionに直接代入しないこと」という制約を定型文として組み込む。プロンプトが統一されることで、担当者が誰であっても同じ品質の生成物が得られる。
GitHubのPRテンプレートに社外共有前チェックリストのセクションを追加し、「オープンリダイレクトの有無を確認済み」チェックボックスをマージ条件の一つとして設定する。Requiredにしておけば確認を飛ばしたままマージすることを防止できる。
四半期に一度、既存の共有中HTMLをバッチスキャンして問題のないことを確認するサイクルを設ける。過去に問題なしと確認したファイルでも、その後の修正でオープンリダイレクトが混入していないとは限らないため、定期的な再確認が安全性を維持するうえで重要だ。
- HTML内の外部script・form action・iframeを確認する
- APIキーやトークンらしき文字列がないか検索する
- 画像・CSS・JSのパスが公開後も解決できるか見る
- noindexと認証を混同せず、必要なら両方設定する
よくある質問
チェックリストの確認は開発者でないと実施できませんか？
URLバーに`?redirect=https://example.com`を追加してリダイレクトが発生するか確認するテストは開発知識がなくても実施できる。ソースコードの目視確認は開発者が担当し、ブラウザテストは非エンジニアでも実施できる役割分担が現実的だ。
レビュー用HTMLをメールに添付して送る場合、URLは関係ないのでオープンリダイレクトのリスクはありませんか？
添付HTMLをローカルで開いた場合も、オープンリダイレクトのコードは実行される。レビュアーがURLパラメータを操作することは少ないが、添付ファイルをそのまま別のサーバーに置いて公開するケースでは同じリスクが生まれる。
確認作業はHTMLのデプロイ前とデプロイ後のどちらで行うべきですか？
デプロイ前のソースコード確認とデプロイ後のブラウザ動作確認の両方を行うことが理想だ。ソース確認だけでは設定の漏れを見落とすことがあり、ブラウザ確認だけではすべてのパターンをテストしきれないため、二段階で実施する。