無料会員登録
「このリンク、本物のURLに見えるのに、なぜか見知らぬサイトへ飛ばされた」——そんな経験をお持ちの方もいるのではないでしょうか。それこそが「悪意あるリダイレクト」の実態です。
リダイレクト（redirect）は、Webサイト運営において欠かせない技術ですが、実装に不備があると攻撃者に悪用され、フィッシング詐欺やマルウェア感染の入口として機能してしまいます。特に近年は、正規ドメインのURLを経由させることで、ユーザーのセキュリティ意識をかいくぐる高度な手口が多発しています。
本記事では、リダイレクトの基本的な仕組みから、危険性が生まれる原因、企業・ユーザー双方に発生する具体的なリスク、そして実際の被害事例と対策まで、会社のセキュリティ担当者が知っておくべき情報を体系的に解説します。社内システムやWebサービスを守るための実践的な知識として、ぜひ最後までお読みください。
リダイレクトとは？基本的な仕組みと種類
リダイレクト（redirect）とは、あるURLにアクセスしたユーザーを、自動的に別のURLへ転送する仕組みのことです。
Webサイトのリニューアルやドメイン変更の際に旧URLから新URLへ誘導したり、ログイン後に特定ページへ遷移させたりと、現代のWebサービスには欠かせない機能として広く活用されています。リダイレクトの主な種類は以下の通りです。
サーバーサイドリダイレクト
サーバーがブラウザに対して転送を指示する方式です。HTTPレスポンスのステータスコードと「Location」ヘッダーを使用して実現します。代表的なものに、恒久的な転送を示す「301リダイレクト（Moved Permanently）」と、一時的な転送を示す「302リダイレクト（Found）」があります。
301はSEOに影響があり、旧URLの評価が新URLに引き継がれます。302は一時的な転送に用いられますが、設定を誤ると悪用されるリスクがあります。
クライアントサイドリダイレクト
JavaScriptやHTMLのmetaタグを使用して、ブラウザ側で転送を実行する方式です。window.location.href = "URL"のようなJavaScriptコードや、HTMLの<meta http-equiv="refresh">タグが該当します。柔軟性が高い反面、セキュリティ上の不備が生じやすく、XSS（クロスサイトスクリプティング）攻撃と組み合わせた悪用が懸念されます。
リダイレクトが危険視される背景
リダイレクト自体は有益な技術ですが、セキュリティ担当者が特に注意しなければならないのは、「誰がどこへ転送されるかを制御できているか」という点です。多くのWebアプリケーションでは、リダイレクト先のURLをURLパラメータとして受け取る設計になっていますが、このパラメータを適切に検証しないまま使用すると、攻撃者が任意のURLを指定できる「オープンリダイレクト」状態となります。
また、ユーザー視点でリダイレクトが危険視される背景としては、「警告なしの自動転送」が挙げられます。多くのブラウザはリダイレクトを自動的に処理するため、ユーザーは気づかないうちに本来とは異なるサイトに移動しています。
さらに、正規ドメインのURLを経由することで、URLフィルタリングやフィッシング対策ツールをすり抜けやすい点も危険性を高めています。IPA（情報処理推進機構）は、オープンリダイレクト脆弱性をWebアプリケーションの重大な脆弱性の一つとして継続的に警告を発しています。
オープンリダイレクト脆弱性とは
オープンリダイレクト脆弱性とは、WebアプリケーションがリダイレクトURLを外部から指定可能な状態になっており、かつそのURLの妥当性を検証していないために、攻撃者が任意のURLにユーザーを誘導できる状態を指します。
OWASP（Open Web Application Security Project）でも重要脆弱性として分類されており、企業のWebサービスにとって無視できないリスクです。オープンリダイレクト脆弱性が生じる主な攻撃手口は、次の3種類に分類されます。
① パラメータ操作型
最も一般的な手口です。例えば、ログイン後に遷移先を指定するhttps://example.com/login?redirect=https://evil-site.comのようなURLを攻撃者が細工し、ユーザーを偽サイトに誘導します。このURLは正規ドメイン（example.com）から始まるため、フィッシング対策をしているユーザーでも見分けがつきにくいという特徴があります。
② HTTPヘッダーインジェクション型
HTTPレスポンスヘッダーに改行コードを混入させることで、悪意あるLocationヘッダーを注入する手口です。Webアプリケーションがユーザーからの入力値をLocationヘッダーに直接設定している場合に発生します。セッションの乗っ取りやクッキーの不正取得につながる危険性があります。
③ JavaScriptリダイレクト型
JavaScriptを用いてブラウザ上でリダイレクトを実行する手口です。window.location.hrefなどにユーザー入力を反映させる実装に脆弱性が存在する場合に悪用されます。後述するXSS攻撃と組み合わせることで、さらに高度な攻撃へと発展するリスクがあります。
リダイレクトによる主なリスク5種
リダイレクトの危険性を正確に理解するには、攻撃者が実際にどのような被害を引き起こすのかを把握することが重要です。以下に、リダイレクトを悪用した攻撃がもたらす主なリスクを5つ解説します。
リスク① フィッシング詐欺への誘導
最も多発している被害です。攻撃者は、正規企業（銀行・ECサイト・SNS等）のURLに見せかけた細工URLを含むフィッシングメールを送付します。ユーザーがクリックすると、正規ドメインを経由しながら偽サイトへ誘導され、IDやパスワード、クレジットカード情報を入力させられます。
正規サイトを経由するため、URLフィルタリングやメールセキュリティをすり抜けやすく、発見が困難です。
リスク② マルウェア配布・感染
偽サイトに誘導した後、ドライブバイダウンロード攻撃と組み合わせてマルウェアを自動インストールさせる手口です。ランサムウェアの感染やスパイウェアによる長期的な情報窃取につながるケースがあり、企業の業務データが暗号化されて身代金を要求されるといった深刻な被害に発展することがあります。
リスク③ XSS（クロスサイトスクリプティング）との組み合わせ攻撃
オープンリダイレクト脆弱性は、XSS攻撃と組み合わさることで被害が大きく拡大します。JavaScriptリダイレクト型の脆弱性を持つサイトでは、javascript:スキームを使った悪意あるスクリプトを埋め込み、セッショントークンの窃取やブラウザ操作の完全制御が可能になる場合があります。OWASPもこの組み合わせ攻撃を特に危険なパターンとして位置付けています。
リスク④ 企業ブランドの信用毀損と法的リスク
自社Webサイトがオープンリダイレクト攻撃の踏み台として悪用された場合、ユーザーからの信頼が大きく損なわれます。「この会社のURLを踏んでフィッシングサイトに飛ばされた」という事実が知れ渡れば、顧客離れや風評被害が生じます。さらに、個人情報の漏洩につながった場合は個人情報保護法に基づく監督省庁からの行政処分や、被害者からの損害賠償訴訟リスクも発生します。
リスク⑤ SEO評価の下落
Googleをはじめとする検索エンジンは、不正なリダイレクトを検知した場合にサイトの評価を大幅に下げます。「クローキング」（検索エンジンとユーザーに異なるコンテンツを表示する行為）に相当すると判断されると、検索インデックスからの削除処分を受ける可能性もあります。
自社サイトがフィッシング攻撃の踏み台とされたことによるSEO評価の低下は、長期にわたるWebマーケティング上の損失につながります。
リダイレクトのリスクは「技術的問題」だけにとどまりません。フィッシング被害・マルウェア感染・ブランド毀損・法的責任・SEO下落という5つのリスクは、いずれも経営判断を必要とするビジネスリスクです。Webサービスを運営する企業は、オープンリダイレクト脆弱性の有無を定期的に確認することが不可欠です。
悪意あるリダイレクト攻撃のフロー図
以下のインフォグラフィックで、攻撃者がどのように正規サイトを悪用してユーザーを偽サイトへ誘導するかの全体フローと、オープンリダイレクト脆弱性の3つの攻撃手口を視覚的に確認できます。
次の図では、リダイレクトを悪用した攻撃がもたらす危険性の全体像を5つの観点から整理しています。
実際の被害事例
事例① 大手SNSプラットフォームを悪用したオープンリダイレクト攻撃（2019年）
2019年、国内外の大手SNSプラットフォームで確認されたオープンリダイレクト脆弱性を悪用した事例があります。攻撃者は、正規のSNSドメインから始まるURLに?redirect_to=パラメータを付加し、フィッシングサイトへの誘導URLを含む大量のスパムDMを送付しました。
受信者はURLが正規ドメイン（sns-service.com）から始まっているために疑わずクリック。結果として、ログイン情報の窃取や、そのアカウントを利用した二次拡散が大規模に発生しました。この事例を受けて、多くのSNSプラットフォームはリダイレクト先URLのホワイトリスト管理と、外部サイトへの遷移時に警告画面を表示する機能を導入しました。
事例② 国内金融機関を装ったリダイレクト型フィッシング詐欺（2021〜2022年）
2021年から2022年にかけて、国内の複数の金融機関（銀行・クレジットカード会社）を装ったフィッシングキャンペーンが相次いで確認されました。IPA（情報処理推進機構）およびフィッシング対策協議会の報告によれば、この攻撃では実在する企業のWebサイトに存在するオープンリダイレクト脆弱性が悪用されています。
攻撃メールには「正規企業のドメインを経由するURL」が記載されており、URLの正規性を確認する習慣を持つビジネスパーソンでも、URLをそのまま信用してしまうケースが続発しました。この手口によって、数千名規模のユーザーのインターネットバンキング認証情報が窃取され、不正送金被害に発展した事例が報告されています。
フィッシング対策協議会は同期間に発出した緊急注意喚起の中で、「URLが正規ドメインで始まっていても安全とは限らない」と明示しました。
ユーザーができる対策
リダイレクト攻撃からユーザー自身を守るためには、日常のセキュリティ意識と具体的な行動習慣が重要です。
① URLの全体を確認する習慣をつける
メールやSNSで届いたリンクをクリックする前に、URLの全体を確認しましょう。正規ドメインで始まっていても、?url=、?redirect=、?goto=などのパラメータの後ろに見知らぬドメインが含まれている場合は要注意です。ブラウザのアドレスバーで最終的な遷移先URLを確認する習慣を身につけましょう。
② 不審なメール内のリンクを直接クリックしない
緊急性を煽る文面のメールやSMSに含まれるリンクは、たとえ正規ドメインのURLに見えても直接クリックしないことが原則です。銀行や公共サービスのサイトには、メール内リンクからではなく、ブラウザのブックマークや直接URL入力でアクセスするよう徹底してください。
③ 短縮URLの最終遷移先を確認する
bit.lyなどの短縮URLはリダイレクトを多段に使用しており、最終遷移先が不明なまま誘導されるリスクがあります。URLを展開して確認できる無料ツール（「URL展開」で検索）を活用し、アクセス前に最終URLを確認する習慣をつけましょう。
④ ブラウザ・OSを常に最新版に維持する
ブラウザやOSの既知脆弱性を突いた攻撃と組み合わせることで、リダイレクト経由のマルウェア感染が成立するケースがあります。セキュリティパッチは公開後速やかに適用し、常に最新状態を維持することが基本的な防衛策です。
⑤ セキュリティソフトの導入とリアルタイム保護の有効化
フィッシングサイトや不審なリダイレクト先をリアルタイムで検知・ブロックする機能を持つセキュリティソフトを導入してください。多くの法人向けエンドポイントセキュリティ製品には、不審なURLへのアクセスを遮断するWebフィルタリング機能が搭載されています。
運営者・開発者向け対策
自社のWebサービスがオープンリダイレクト攻撃の踏み台とならないよう、運営者・開発者は以下の対策を実施することが求められます。
① ホワイトリストによるリダイレクト先の制限
リダイレクト先URLをホワイトリストで厳密に管理し、許可されたドメイン・URLのみに転送を許可する実装を徹底することが最も効果的な対策です。「任意のURLにリダイレクトできる機能」は、原則として廃止するか、自社ドメイン内に限定する設計に変更することを検討してください。OWASPのガイドラインでも、この「信頼できる宛先リストの管理」が第一の推奨対策として挙げられています。
② URLパラメータのバリデーション・サニタイズ
リダイレクト先URLを受け取るすべてのパラメータに対して、形式チェック・エスケープ処理・入力値の検証を必ず実装します。特に、外部ドメインへのリダイレクトを許可している場合は、URLの正規化処理を行い、javascript:スキームや改行コードを含む入力を無効化する処理を追加してください。
③ セキュリティヘッダーの適切な設定
HTTPレスポンスヘッダーを適切に設定することで、XSSとの組み合わせ攻撃を防止できます。具体的には、Content-Security-Policy（CSP）でスクリプトの実行元を制限し、X-Frame-Optionsでクリックジャッキング攻撃を防ぐ設定が有効です。Strict-Transport-Security（HSTS）を設定することでHTTPSの強制も実現できます。
④ WAFの導入
Webアプリケーションファイアウォール（WAF）を導入することで、オープンリダイレクト攻撃に特有のパターン（外部URLを含むパラメータ等）を自動検出・遮断できます。WAFはアプリケーションコードを変更せずに追加できるセキュリティ層として、既存システムへの導入も比較的容易です。
⑤ 定期的な脆弱性診断の実施
OWASP ZAPやBurp Suiteなどの脆弱性診断ツールを使ったセルフチェック、または専門業者によるペネトレーションテストを定期的に実施し、オープンリダイレクト脆弱性が存在しないかを確認する体制を整えましょう。特にWebアプリケーションの改修・機能追加を行った際は、リダイレクト関連の実装を必ずレビュー対象に含めてください。
以下のインフォグラフィックで、ユーザー向けと運営者・開発者向けの対策を一覧で確認できます。
よくある質問（FAQ）
Q. リダイレクト警告（「このページはリダイレクトを繰り返しています」）が表示されるのはなぜですか？
リダイレクト警告は、主にブラウザのCookieやキャッシュの問題、またはサイト側でリダイレクトのループが発生している場合に表示されます。
Cookie・キャッシュを削除してから再度アクセスすることで解消されるケースが多いですが、繰り返し発生する場合は当該サイトのセキュリティ設定に問題がある可能性があります。アクセス先が社外の不審なサイトの場合は、セキュリティ担当者への報告を推奨します。
Q. HTTPからHTTPSへのリダイレクトは安全ですか？
適切に設定されたHTTPからHTTPSへの強制リダイレクト（301リダイレクト＋HSTS）は安全な実装であり、むしろ推奨されるセキュリティ対策です。ただし、設定が不完全な場合は「SSLストリッピング攻撃」を受けるリスクがあります。
特に、HSTSの設定を伴わないHTTP→HTTPSリダイレクトのみでは、中間者攻撃に対して脆弱な場合があります。自社サービスのSSL/TLS設定は定期的に確認・強化してください。
Q. 短縮URLを使ったリダイレクトは危険ですか？
短縮URL自体は危険ではありませんが、最終遷移先が不明なままアクセスしてしまうリスクがあります。業務でのURL共有には、信頼できる社内ツールや、最終URLが確認できる短縮URLサービスを使用することを推奨します。また、社内ルールとして「不審な短縮URLはURLチェッカーで確認してからアクセスする」という手順を徹底することが有効です。
Q. 自社サイトがオープンリダイレクト攻撃の踏み台になっていないか確認する方法はありますか？
自社サイトのURLパラメータに外部URLを入力してアクセスし、その外部URLにリダイレクトされないかを確認する方法が基本的なテストです。
専門的には、OWASP ZAP（無料）やBurp Suiteといった脆弱性診断ツールを用いた自動スキャン、または外部のセキュリティベンダーによる脆弱性診断（Webアプリ診断）の実施が推奨されます。また、Googleサーチコンソールでクロールエラーや不審なリダイレクトの警告が出ていないかも確認してください。
Q. オープンリダイレクト脆弱性は法令上の問題になりますか？
オープンリダイレクト脆弱性そのものを直接罰する規定は現時点では存在しませんが、この脆弱性が原因でフィッシング詐欺の踏み台とされ、個人情報の漏洩が発生した場合は、個人情報保護法上の「安全管理措置」義務違反として行政指導・勧告の対象となる可能性があります。
また、経済産業省が定める「サイバーセキュリティ経営ガイドライン」では、Webアプリケーションの脆弱性管理が経営層に求められる対策として明示されています。
Q. リダイレクト設定で使う301と302はどちらがセキュリティ上優れていますか？
恒久的な転送には301リダイレクトが推奨されますが、セキュリティ上の優劣はリダイレクト先の検証の有無によって決まります。
どちらのステータスコードを使用するにせよ、リダイレクト先URLがホワイトリストに登録されたものであること、外部から任意のURLを指定できない実装になっていることが最も重要です。302リダイレクトは一時的な転送に使用される設計上、セッション管理と絡む実装が多く、特に慎重な設計が必要です。
まとめ
リダイレクトはWebサービス運営において不可欠な技術ですが、実装に不備があると攻撃者にとって格好の武器となります。特にオープンリダイレクト脆弱性は、正規ドメインのURLを経由することでユーザーの警戒心を巧みにくぐり抜け、フィッシング詐欺・マルウェア感染・企業ブランドの毀損・SEO評価の下落という深刻な被害を引き起こします。IPA（情報処理推進機構）もOWASPも継続的に警告を発しているこの脆弱性は、Webサービスを運営するすべての企業にとって対策が急務です。
ユーザー側ができることとしては、リンクのURL全体を確認する習慣、メール内リンクへの慎重な対応、短縮URLの最終遷移先確認、ブラウザ・OSの最新維持、セキュリティソフトの活用が有効です。一方、運営者・開発者としては、ホワイトリストによるリダイレクト先制限、URLパラメータのバリデーション・サニタイズ、セキュリティヘッダーの適切な設定、WAFの導入、そして定期的な脆弱性診断の実施が基本的な対策となります。
特に「任意のURLへリダイレクトできる機能」を持つWebアプリケーションは、最優先で実装を見直すことを強く推奨します。セキュリティの脅威は日々進化しており、リダイレクトを悪用した攻撃も手口が高度化しています。今日の対策が明日の標準になるサイバーセキュリティの世界において、定期的な情報収集と継続的な対策の見直しが欠かせません。
自社のWebサービスにオープンリダイレクト脆弱性がないかを今すぐ確認し、セキュリティ担当者・開発者・経営層が一体となった組織的な対策体制を構築することが、企業の信頼と顧客を守る最善の方法です。
書籍「セキュリティ対策の基礎知識」
メルマガ登録でプレゼント！
セキュリティ対策で何をして良いかわからない
企業の情シス部門の方必見！
関連コラム（あわせて、以下の記事もよく読まれています）
バッファオーバーフローとは？攻撃の手口・対策方法をわかりやすく解説
【OWASP ZAP】の使い方！無料で脆弱性診断する方法
オープンセキュリティ
脆弱性診断士とは？必要な資格やスキルマップについて
OWASP ZAPのインストール方法【Windows 10】
クリックジャッキング
DDoS攻撃対策に欠かせないWAF！抑えるべきポイントを解説
CWE
![中小企業の情報瀬キィリティ相談窓口[30分無料]](/wp-content/uploads/2023/07/bnr_footer04.png)
リダイレクトが本来の目的で使われている場面としては、ドメイン変更・サイトリニューアル後の旧URL転送、HTTPからHTTPSへの強制転送（常時SSL化）、ログイン後の特定ページへの遷移、多言語サイトにおける言語別ページへの自動振り分け、などが挙げられます。これらはいずれも正当な用途であり、適切に実装されていれば問題ありません。問題が生じるのは、リダイレクト先の検証が不十分なケースです。