フィッシングや情報漏洩に繋がる攻撃 オープンリダイレクトの概要と対策
オープンリダイレクト（Open Redirect）攻撃は、リダイレクト処理の実装不備を悪用し、被害者となるユーザを意図しない URL に誘導をする攻撃手法・脆弱性です。
意図しないリダイレクトを発生させるだけですと、大きな問題は起こせないと思われるかもしれませんが、正規ドメインから悪性ドメインへ意図しない誘導を行える場合、フィッシング詐欺などに悪用される可能性があります。
フィッシング詐欺に悪用された際のオープンリダイレクトは、危険度が高まります。
本記事では、オープンリダイレクトの原因と対策について触れたあと、対策方法や、開発者としてこのオープンリダイレクトを見つける方法についてご紹介します。
また、オープンリダイレクトを使った高度な攻撃手法（OAuth2 を狙ったオープンリダイレクト）の例について解説します。
オープンリダイレクトの概要
オープンリダイレクトは、「正規サービスのドメインから悪性ドメインに誘導できる」といった問題を発生させる脆弱性です。
この問題は、正規サービス自体にリダイレクト処理があり、それが悪用可能な実装になっている場合に発生します。
例を見ていきましょう。
とあるサービスに以下のような URL があったとします。
上記はログインページの URL で、 redirect というパラメータを所持しています。
サイトによっては、ログインが成功した場合にこのような外部パラメータを利用し、リダイレクト先を制御していることがあります。
この例の場合だと、ログイン成功時などに http://yamory.io/dadshboard へ推移するといった動きを行います。
では、上記例を少し変更し redirect パラメータに別のドメインを設定してみましょう。
すると、ログイン成功時のリダイレクト先が、外部ドメインである http://example.com に変わってしまいます。
このように、意図しないリダイレクトを発生させられるバグがオープンリダイレクトという脆弱性になります。
オープンリダイレクトの悪用 - フィッシング詐欺
先ほどの例だけでは「URL に変なドメインを入力させて誘導するのと大差ないじゃないか」と思われるかもしれません。
しかし、少し手の込んだ方法を取ることで、フィッシング詐欺としての脅威度はグンと上がります。
たとえば、先ほどの例と同様に、正規サービスのログイン画面でオープンリダイレクトがあったとします。
攻撃者はこの脆弱性を悪用し、ログインが成功したら、攻撃者が管理するフィッシングサイトに誘導するように仕向けます。
この時、フィッシングサイトのデザインを攻撃対象となる正規サービスのログイン画面そっくりにしておきます。
また、赤文字で「ログインに失敗しました。再度 ID・パスワードを入力してください」といった文言も付け加えておきます。
すると被害者はログインが成功し、悪意のあるサイトへリダイレクトした時に、（悪性ドメイン上の）パスワードを再度入力するよう書かれた文言を発見するでしょう。
この時、ほとんどのユーザーは「パスワードのタイプミスをしたんだろう」と勘違いをしてしまうはずです。
勘違いをしたユーザーは、再度パスワードを入力してしまうかもしれません。
結果的にフィッシングサイトであるにも関わらず、ユーザーは自身の ID / Password を入力・漏洩させてしまいます。
このように、正規のサイトから気がつかないうちに誘導された場合、例え警戒心があるユーザーであっても、誤って個人情報を入力してしまうケースもあるでしょう。
オープンリダイレクトは、シンプルな機能不備で危険度も高くないように見えますが、高度なフィッシング詐欺などで悪用されると非常に厄介な問題になりえます。
オープンリダイレクトが発生する傾向と特徴
オープンリダイレクトは「外部パラメータを使ってリダイレクト処理をする」箇所によって発生することがほとんどです。
そのため、リダイレクト処理が発生する箇所を特定することが重要となります。
また「外部パラメータを使ってリダイレクト処理をする」という特徴は、言い換えると以下のような条件になります。
- パラメータ名が url, to, sendTo, redirect などの、URL が入りそうな名前になっている
- パラメータ値が URL になっている
これらの特徴がある処理に気を配ることで、オープンリダイレクトの問題を検知しやすくなります。
また、開発中・コードレビュー中のコードにこれらの特徴が出てきた場合は、オープンリダイレクトの問題がないかを確認すると良いでしょう。
オープンリダイレクトの対策
オープンリダイレクトの対策として、一番有力な方法は「外部パラメータを使ってリダイレクトをしないようにする」というものです。
こうすることで、オープンリダイレクトを悪用するような入り口を無くすことができます。
しかし、場合によっては外部のパラメータを扱ってリダイレクトをしたいという場合もあるでしょう。
その場合には、以下の方法が考えられます。
- ホワイトリストを作成し、その URL のみにリダイレクトする
- 入力チェックを行う
しかし、これらの方法はしばしば対策をすり抜けられる例が報告されています。
URL チェックの対策の難しさについては、同様の問題（URL の取り扱いによって発生する）SSRF の脆弱性でも発生します。
なぜ URL 入力のチェックが難しいのかが気になる方は、SSRF の記事のどのように SSRF を含んだコードを修正すればよいのか を参考にしていただければと思います。
高度なオープンリダイレクトの攻撃 - OAuth2 トークン漏洩の例
余談になりますが、オープンリダイレクトは発生する状況によって危険度が上がり、それ単体でクリティカルな脆弱性となる場合があります。
それは、オープンリダイレクトによって、Referrer から Token などの機微情報が漏洩するケースです。
OAuth という有名な認可プロトコルでは、処理フローの中でリダイレクトが発生する箇所があります。
このリダイレクト処理の中にオープンリダイレクトの問題が存在した場合、外部ドメインへ意図しないリダイレクトを行ってしまいます。
また、このプロトコルでは、URL に機微データに当たる Token を保持して処理を行う部分があります。
この 2 つを掛け合わせることで、リダイレクト先の悪性ドメインは「Referer ヘッダ（どの URL から来たのか）に存在する Token を取得することができる」という攻撃が成り立ちます。
OAuth は認可プロトコルであるため、これらのトークンが漏れた場合の影響はとても大きくなります。
以上から、発生する状況などによっては、クリティカルな問題になりえる脆弱性であるといえるでしょう。
さいごに
オープンリダイレクト攻撃は、フィッシング詐欺や情報漏洩に繋がる脆弱性を狙った攻撃で、気を抜けない問題です。
そのため、脆弱性診断やコードレビューなど、複数の方法で問題を検知・対策していくことが重要となります。
また、自らが書いたコードの安全性は担保できていたとしても、現在利用しているフレームワークやライブラリの内部に別の脆弱性が発見されるケースもありえます。
これらの脆弱性を把握するには、定期的にライブラリなどの棚卸しや脆弱性の発行状況をウォッチしていく必要があるでしょう。
また、システム管理者はユーザーを被害に巻き込まないためにも、サイバー攻撃への対応策は抜け目なく実施することをおすすめします。
Web に携わる開発者・管理者として、全体像に目を向けながらセキュアな開発を心がけましょう。
さいごになりますが、yamory はオープンソースソフトウェアの脆弱性と、その脆弱性に関連する攻撃情報のモニタリングをすることができる脆弱性管理ツールです。
お使いの Web アプリケーションで危険となりうる脆弱性を自動的に検出できるため、よりセキュアなシステム構築の助けになるかと思います。
無料でトライアルもできますので、ぜひ一度お試しください。
