LASSIC Media らしくメディア
オープンリダイレクトとは｜偽サイト誘導の手口と対策
Webサイトのセキュリティに関する話題で、「オープンリダイレクトの指摘が脆弱性診断でありました」「リダイレクトの処理に注意が要ると言われた」といった場面に出会うことはないでしょうか。オープンリダイレクトは、単体では見過ごされがちですが、フィッシング（偽サイトへの誘導）などと組み合わされると被害を大きくしうる脆弱性で、OWASPなどでも古くから注意が促されてきました。IT事業部でシステムの発注や運用に関わる立場であれば、名前は聞いたことがあっても、それが具体的に何を突く問題で、なぜ危ないのか、どう防ぐのかまでは説明しにくいかもしれません。とはいえ、その大まかな仕組みを理解しておくと、ベンダーの提案や脆弱性診断の報告を受けたときに、対策が妥当かどうかを判断する助けになるでしょう。本記事では、攻撃コードの書き方といった実践的な手順ではなく、オープンリダイレクトとはそもそも何を突く問題なのか、なぜ起こり、どんな被害につながり、どう防ぐのかを、発注・運用の視点から順に整理します。専門的な用語をすべて覚える必要はありませんが、「正規サイトのリンクなのに、外部の偽サイトへ飛ばされる」という勘所をつかんでおくと、セキュリティの会話が理解しやすくなるはずです。
オープンリダイレクトとは何か
オープンリダイレクト（Open Redirect）とは、Webサイトが備える「別のページへ自動的に転送する（リダイレクトする）」機能を悪用され、利用者を、そのサイトが意図しない外部のサイトへ飛ばされてしまう問題です。「オープン」は、転送先が外部にまで開かれてしまっている、という状態を表しています。
もう少しかみ砕いてみましょう。Webサイトには、ログイン後に元のページへ戻す、キャンペーンのリンクを踏むと目的のページへ送る、といった「転送」の仕組みがしばしば見られるものです。このとき、転送先のアドレスを、URLの一部（パラメータ）として受け取る作りになっていることがあります。もし、その転送先に自サイト内かどうかの確認をしていないと、攻撃者は転送先の部分に外部の偽サイトのアドレスを仕込めます。その結果、利用者が正規サイトのリンクをクリックしたつもりでも、実際には攻撃者が用意した外部の偽サイトへ送り込まれてしまうのです。
この問題がやっかいなのは、利用者に示されるリンクが「正規サイトのアドレスから始まっている」点にあります。見慣れたドメインなので、利用者は信頼してクリックしてしまうのです。そこが、後で触れる「だまされやすさ」につながります。情報処理推進機構（IPA）やOWASPでも、こうした転送機能の危うさが注意点として挙げられています。
なぜ起こるのか（攻撃の仕組み）
オープンリダイレクトが成立してしまう根っこには、「転送先を利用者からの入力で決めているのに、その転送先が妥当か（自サイト内など、許してよい相手か）を確認していない」という問題があります。
転送機能は、それ自体は便利で、正当な用途があります。問題は、その転送先を外部から自由に指定できてしまうことです。攻撃者は、正規サイトの転送用URLの、転送先を表す部分に、自分が用意した偽サイトのアドレスを紛れ込ませます。そして、そのURLをメールやSNSなどで利用者に送りつけるのです。利用者から見れば、リンクの先頭は見慣れた正規サイトのアドレスなので、つい信頼してクリックしてしまいます。ところが正規サイトは、指定された転送先へ、その妥当性を確かめないまま利用者を送り出してしまうのです。次の図は、この流れを単純化して示したものです。
ここで大切なのは、オープンリダイレクトは「正規サイトの信頼」を借りて利用者をだます点に本質があるということです。正規サイト自体が乗っ取られているわけではないのに、その転送機能を通じて、利用者が危険な外部サイトへ導かれてしまいます。だからこそ、対策は「転送先を見張り、勝手な外部への転送を許さない」ことに向かいます。
この記事のポイント
- オープンリダイレクトは、サイトの転送機能を悪用して利用者を外部の偽サイトへ飛ばす問題です。
- 原因は、転送先を利用者の入力で決め、その妥当性を確認していないことにあります。
- リンクが正規ドメインから始まるためだまされやすく、転送先の制限が対策の中心です。
どんな被害につながるのか
オープンリダイレクトは、単体では「外部サイトへ飛ばされる」だけに見えますが、他の手口と組み合わさると被害が広がります。代表的なものを挙げておきましょう。
一つ目はフィッシングの踏み台です。正規サイトのアドレスから始まるリンクで利用者を信頼させ、本物そっくりの偽ログイン画面へ誘導して、IDやパスワードを入力させる手口につながります。二つ目は認証にかかわる情報の窃取です。ログインや外部連携の流れの中で転送が悪用されると、認証に用いる一時的な情報が、攻撃者の用意した先へ渡ってしまう場合があります。三つ目は他の攻撃への悪用です。利用者を任意の場所へ飛ばせること自体が、より大きな攻撃を組み立てる部品として使われることがあります。
共通しているのは、いずれも「正規サイトへの信頼」が悪用される点です。利用者は、正規サイトのリンクだからと油断し、飛ばされた先が偽物だと気づきにくくなります。オープンリダイレクトが単体では軽視されがちなのに油断できないのは、こうして他の攻撃と結びつくと、正規サイトの信頼を土台に被害が拡大しうるためだといえるでしょう。
身近な流れで想像してみましょう。ある利用者のもとに、正規サービスからのお知らせを装ったメールが届いたとします。本文のリンクは、たしかにそのサービスの見慣れたドメインから始まっているのです。利用者は疑わずにクリックしますが、そのリンクには外部の偽サイトへの転送が仕込まれており、開いた先は本物そっくりの偽ログイン画面——。利用者は正規サービスにログインしているつもりで、IDとパスワードを攻撃者に手渡してしまう、という具合です。リンクの見た目が本物だからこそ、警戒がゆるんでしまうわけです。
なぜだまされやすいのか
オープンリダイレクトの怖さは、その「だまされやすさ」にあります。ここを押さえておくと、なぜ軽視できないのかがつかめます。
利用者が不審なリンクを見抜く手がかりの一つは、リンク先のドメイン（アドレスの先頭部分）です。見慣れないドメインであれば警戒しますが、オープンリダイレクトを使われると、リンクの先頭は正規サイトの見慣れたドメインになります。実際に飛ばされる外部サイトのアドレスは、URLの後半のパラメータに隠れているため、ぱっと見では気づきにくいのです。さらに、URLを短縮するサービスなどと組み合わされると、リンク先の判別はいっそう難しくなります。つまり、利用者側の注意力だけに頼るのは限界があり、だからこそサイトを提供する側が転送先を制限しておくことが要になります。
基本の対策と発注・運用の観点
オープンリダイレクトにも、有効性が知られた対策があります。中心になる考え方と、発注・運用で押さえておきたい観点を整理しておきましょう。
| 対策 | 考え方 |
|---|---|
| 転送先を外部から指定させない | 最も基本の対策。転送先を利用者の入力で決めるのをやめ、番号や識別子で選ばせ、実際の宛先はシステム側で対応付けます。入力が転送先を直接決めない形にします。 |
| 許可リストによる確認 | やむを得ず転送先を受け取る場合は、あらかじめ許してよい宛先を決めておき、それ以外への転送は拒否します。自サイト内に限定するのも有効です。 |
| 相対パスに限定する | 転送先を、外部サイトを指せる形ではなく、自サイト内の位置だけを表す形に限定します。外部ドメインへ飛ばせないようにする考え方です。 |
| 外部へ出る際の一枚はさみ | やむを得ず外部へ転送する場合は、「外部サイトへ移動します」と知らせる確認画面をはさみ、利用者が気づけるようにする手立ても選べます。 |
中心になるのは、転送先を利用者の入力で自由に決めさせないという考え方です。番号や識別子で選ばせる、許可リストで確認する、相対パスに限定する——こうした作り込みで、外部への勝手な転送を防ぎます。「正規サイトの信頼を悪用される」という性質上、利用者への注意喚起だけに頼らず、サイト側で転送先を制限しておくことが要になります。
発注・運用の立場では、いくつかの観点を押さえておくとよいでしょう。第一に挙げられるのが、転送機能の把握になります。ログイン後の戻り先や、外部リンクへの誘導など、転送先を入力で受け取る機能があるか、提案や仕様の中で確認しておくと、リスクの所在がつかめます。第二に、対策方針の確認です。そうした機能について、転送先を外部から自由に指定できない作りになっているかを尋ねておくと、核心をつかめます。第三に、脆弱性診断の活用です。リリース前や定期的なタイミングで診断を受けると、作り込みの不備を早い段階で見つけられます。なお本記事は攻撃手法の実践的な手順ではなく、オープンリダイレクトという脅威の考え方と、発注・運用で押さえたい観点に焦点を当てているものです。個別の対策の実装や診断は、実績のあるベンダーや専門機関への相談が別途必要になります。
まとめ
- オープンリダイレクトは、サイトの転送機能を悪用して、利用者を外部の偽サイトへ飛ばす問題です。
- 原因は、転送先を利用者の入力で決め、その妥当性（自サイト内かなど）を確認していないことにあります。
- リンクが正規ドメインから始まるため利用者がだまされやすく、フィッシングなどの踏み台にされます。
- 単体では軽視されがちですが、他の攻撃と結びつくと正規サイトの信頼を土台に被害が広がります。
- 対策の中心は、転送先を入力で自由に決めさせず、許可リストや相対パスで制限することです。
- 利用者の注意力だけに頼らず、サイト側で転送先を制限しておくことが要になります。
- 本記事は攻撃手法の手順ではなく、脅威の考え方と発注・運用の観点の整理を狙いとしています。
よくある質問
オープンリダイレクトは単体ではあまり危険ではないと聞きましたが本当ですか。
単体では「外部サイトへ飛ばされるだけ」に見えるため、影響が小さいと受け取られがちです。しかし、フィッシングや認証にかかわる情報の窃取など、他の手口と組み合わされると被害が大きくなりえます。とりわけ、正規サイトのアドレスから始まるリンクで利用者を信頼させられる点が、他の攻撃の成功率を高めてしまうのです。そのため、単体での影響が限定的に見えても、放置してよいわけではなく、転送先の制限といった対策をしておくことが望まれます。
利用者がURLをよく確認すれば防げるのではないですか。
利用者の注意も助けにはなりますが、それだけに頼るのは無理があります。オープンリダイレクトでは、リンクの先頭が正規サイトの見慣れたドメインになり、実際に飛ばされる外部サイトのアドレスはURLの後半に隠れているのです。URL短縮サービスと組み合わされると、いっそう判別が難しくなります。人の注意力には限界があるため、サイトを提供する側が転送先を制限し、そもそも外部へ勝手に飛ばせないようにしておくことが根本的な対策になります。
リダイレクト機能自体をなくすべきですか。
なくす必要はありません。リダイレクト（転送）は、ログイン後に元のページへ戻すなど、正当で便利な用途が多くあります。問題なのは、転送先を外部から自由に指定できてしまうことです。対策は機能をなくすことではなく、転送先を利用者の入力で自由に決めさせないことにあります。番号や識別子で選ばせる、許可リストで確認する、自サイト内の相対パスに限定するといった作りにすれば、利便性を保ちながら悪用を防げます。
WAFを導入すればオープンリダイレクト対策は十分ですか。
WAFは補助的な備えにはなりますが、それだけで十分とはいえません。オープンリダイレクトは、正規の転送機能に外部アドレスを指定する形で成立するため、通信の見た目が正常に近く、入り口での検知だけではすり抜ける余地が残ります。根本的な対策は、プログラム側で転送先を外部から自由に決めさせないことです。許可リストや相対パスへの限定といった作り込みを土台に据え、WAFはそれを補う一枚と位置づけて多層で守るのが基本になります。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、オープンリダイレクトをはじめとする脆弱性を作り込まないための設計・実装から、転送先を外部から指定させない作り込み、既存システムの対策状況の確認、脆弱性診断を踏まえた改修までを一貫して支援する体制です。転送機能のリスクや、診断で受けた指摘への対応にお困りの際もご相談いただけます。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。セキュリティの作り込みに不安がある段階からでも、ご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
