はじめに

はじめまして。MBSDでWeb診断をしている荒牧です。突然ですが、みなさんはCDやゲームソフトなどのケースを開けた時、別のCDやゲームソフトが入っている問題に遭遇したことはあるでしょうか。最近は音楽もゲームもダウンロードが主流でめっきりなくなりましたよね。実はWebの脆弱性にも似たような問題が存在します。そんなわけで、本ブログ記事では、目的のWebサイトのURLを開くと別のWebサイトに遷移してしまう脆弱性、オープンリダイレクトの概要と原因、その対策について説明します。またオープンリダイレクトが深刻度の高い脆弱性に繋がるケースも併せて紹介させていただきます。
※ちなみに筆者が報告したオープンリダイレクトの脆弱性が昨年末に公開されています(https://jvn.jp/jp/JVN79798166/)

オープンリダイレクトとは

オープンリダイレクトとは、Webアプリケーション内の他ページや外部サイトに遷移するためのリダイレクト機能を悪用し、被害者を攻撃者が用意したページに誘導することが可能になる脆弱性です。Webアプリケーションの中には以下の図のようなリダイレクト機能を備えたものが存在します。 上図のような場合、以下のようにクエリストリングでリダイレクト先のURLを渡すことで、指定されたURLに遷移が発生する実装がよく見られます。

https://example.co.jp/?redirect=(リダイレクト先URL)

オープンリダイレクトの悪用イメージ

上記の機能を提供するWebアプリケーションがオープンリダイレクトに脆弱な場合、以下の図のように攻撃者が変更したURLを被害者にアクセスさせることで攻撃者の用意したページに誘導することが可能になります。

https://example.co.jp/?redirect=(攻撃者が用意したページのURL)

アクセスするドメイン自体は、脆弱なWebアプリケーションのドメインであるため、被害者が悪意のあるリンクであることを見破りにくいです。 被害は攻撃者の用意したリダイレクト先のコンテンツにより様々ですが、誘導先のコンテンツとしてクレジットカード情報やログインID、パスワードなどの入力を促す内容を表示することで、被害者の機密情報を窃取するなどが考えられます。また検索エンジンの検索結果の汚染や、リダイレクトの実装方法によっては、クロスサイトスクリプティングに繋がる可能性もあります。

オープンリダイレクトの発生原因

オープンリダイレクトが発生する条件として以下の2つが共に成り立つ必要があります。

1. 遷移先を動的に指定可能にしている
2. 遷移先の検証が適切に行われていない

1つ目の条件である「遷移先を動的に指定可能にしている」は、そもそもリダイレクト先を動的に指定できない状態であれば、オープンリダイレクトの問題が発生しないことは自明です。
2つ目の条件である「遷移先の検証が適切に行われていない」は、サーバ側でリダイレクト先の検証を適切に行うことで意図しない遷移先に遷移することを防ぐことが可能なため、必要な条件になります。
リダイレクト先の検証が適切に行われていない一例としては次のような状況が考えられます。 リダイレクト先としてブラウザからWebアプリケーションに渡されるパラメータが「https://example.co.jp」から始まることを確認するロジックがWebアプリケーションに対策として実装されているとします。その場合、「https://evil.example.com (攻撃者が管理するドメイン)」がパラメータとしてブラウザからWebアプリケーションに渡された場合、遷移は発生しません。しかし以下のようなパラメータがリダイレクト先のパラメータとして渡された場合、「https://example.co.jp」から始まっているため、リダイレクトは発生してしまいます。

https://example.co.jp.evil.example.com

上記は「https://example.co.jp」から始まっているものの、evil.example.comのサブドメインであるため攻撃者が任意のコンテンツを配置することが可能です。このようにサーバ側でのリダイレクト先の検証が不適切な場合、攻撃者がURLを細工することで検証のバイパスが可能なため、サーバ側でリダイレクト先を検証する場合は適切に検証を行う必要があります。

オープンリダイレクトへの対策

上記の原因を踏まえ、オープンリダイレクトへの対策としては以下のような方法があります。

1. 遷移先をパラメータとして受け取らず静的にする
2. 遷移先を自由に指定できないようにする
3. 遷移先の検証を適切に行う
4. 遷移先の改ざんを検証する

以下にそれぞれの対策について記載します。

遷移先をパラメータとして受け取らず静的にする

1つ目の対策は、リダイレクト先を固定する方法です。そもそもリダイレクト先を動的に指定する必要がないのであれば、ブラウザからWebアプリケーションにパラメータとしてリダイレクト先URLを受け渡すのを止め、リダイレクト先を固定することでオープンリダイレクトの問題は発生しません。しかしWebアプリケーションの要件として動的に遷移する必要がある場合、本対策は行えず、以降のいずれかの対策を講じることになります。

遷移先を自由に指定できないようにする

2つ目の対策の一例としては、サーバ側でリダイレクト先のURLに識別コードを割り当て、識別コードをブラウザからWebアプリケーションにパラメータとして渡すことで遷移を行う方法が挙げられます。リダイレクト先として直接URLを受け渡すのではなく、識別コードを受け渡すことで、任意のURLを設定することができなくなり、オープンリダイレクトの問題は発生しません。しかし事前にリダイレクト先を想定することが難しい場合などには、本対策は行えません。

例) 00 -> https://example.jp

01 -> https://example.co.jp

URL例) https://example.co.jp/?redirect=00

遷移先の検証を適切に行う

3つ目の対策の一例としては、ブラウザからWebアプリケーションにリダイレクト先として渡されたURLをURLパーサや正規表現などを用いてサーバ側で検証したり、WAF等を用いてアクセス制御したりすることでWebアプリケーションの設計者が意図したリダイレクト先ドメインの場合のみWebアプリケーションが遷移を行うという方法です。前述の2つの対策に比べ、ある程度柔軟にリダイレクト先を指定することができます。その一方、前述の例のようにサーバ側での検証方法が不適切だと攻撃者が細工することでサーバ側の検証をバイパスされてしまう恐れがあります。

遷移先の改ざんを検証する

4つ目の対策の一例としては、MAC(Message Authentication Code)などを利用し、リダイレクト先URLが攻撃者によって改ざんされていないことをサーバ側で確認した上で、Webアプリケーションによる遷移を行うという方法です。サーバ側でリダイレクト先URLの改ざんが検知された場合、Webアプリケーションによる遷移は行わず、エラーメッセージなどを返します。本対策もWebアプリケーションによってリダイレクト先の柔軟性は高い一方、WebアプリケーションでのMACの実装方法やサーバ側での検証方法に問題があった場合、攻撃者によってMACの偽造や検証のバイパスを行われる可能性があります。

オープンリダイレクト対策のバイパス方法について

「オープンリダイレクトの発生原因」で軽く紹介しましたが、対策としてリダイレクトする遷移先の検証を行う場合、対策がサーバ側で適切に実装されていなければ、攻撃者によって容易にバイパスされてしまう可能性があります。先程の例では攻撃者の所有するドメインのサブドメインとして脆弱なWebアプリケーションのドメインを内包する方法を紹介しましたが、他にも以下のような方法が知られています。（脆弱なWebアプリケーションのドメインとしてexample.co.jp、攻撃者の所有するドメインとしてevil.example.comを想定します）
※以下の検証ではブラウザとしてGoogle Chrome(98.0.4758.102 (Official Build) (64-bit))、Firefox(97.0.1 (64 ビット))を使用しました

1. http://example.co.jp?redirect=http://evil.example.com?example.co.jp
2. http://example.co.jp?redirect=http://evil.example.com/example.co.jp
3. http://example.co.jp?redirect=http://evil.example.com#example.co.jp
4. http://example.co.jp?redirect=http://evil.example.com\example.co.jp
5. http://example.co.jp?redirect=http://example.co.jp@evil.example.com

1から3番目の方法は、それぞれ脆弱なWebアプリケーションのドメインをクエリストリング、ファイルパス、フラグメントとして扱うように細工することでURL中に脆弱なWebアプリケーションのドメインが存在するものの、リダイレクト先は攻撃者の所有するドメインになります。
4番目の方法はブラウザがバックスラッシュ(円記号)をスラッシュに置き換えるため2番目の方法と同じURLが生成され、攻撃者の所有するドメインにリダイレクトが発生します。
5番目の方法はユーザ名やパスワードを指定したアクセス方法として用いられる方法です。Basic認証やSSHでのアクセスなどでよく目にする形式だと思います。上記の例ではユーザ名やパスワード部分に脆弱なWebアプリケーションのドメインを配置することで、リダイレクト先は攻撃者の所有するドメインになります。ちなみに検証する中で、Google Chromeは何の問題もなくリダイレクトが発生しましたが、Firefoxの場合、以下のような確認画面が出現することを確認しています。 上記確認で「はい」を選択することでリダイレクト先に遷移しますが、利用者に不信感を与え、攻撃であると気づかれる可能性は上がります。
実際に診断をしていてもURLの検証がバイパスできる場合、上記5パターンのどれかでバイパスできてしまう場面がほとんどです。

オープンリダイレクトが比較的大きな被害に繋がる例

オープンリダイレクトは悪用に被害者の関与が必要なことや、その被害内容などから脆弱性としての深刻度は低く見積もられがちです。しかし深刻度が低いからと言って甘くみていると大きな被害に繋がることがあります。最後にオープンリダイレクトから大きな問題に繋がった、または繋がる可能性のある例を紹介します。
実際に弊社が過去に検出したオープンリダイレクトの中にはリダイレクト先のURLとしてLocationヘッダに以下のようなURLが生成されるケースがありました。

Location: https://(攻撃者が所有するリダイレクト先URL)/(脆弱なWebアプリケーションでセッションIDとして利用される情報)

上記のようなリダイレクトが発生した場合、攻撃者に被害者のセッションIDが漏えいしてしまい、なりすましの被害にあう可能性があります。

またバグバウンティサイト「HackerOne」には、オープンリダイレクトを利用してアカウント乗っ取りに繋がったケースも報告されています(ちなみに報奨金は8000ドル)。
https://hackerone.com/reports/206591

その他にはオープンリダイレクトを利用することでSSRF(サーバサイドリクエストフォージェリ)の対策をバイパスする方法も知られています。こちらはPortSwigger社が無料で提供しているラボ環境で実際に攻撃を体験することができます。
https://portswigger.net/web-security/ssrf/lab-ssrf-filter-bypass-via-open-redirection

おわりに

オープンリダイレクトはクロスサイトスクリプティングやSQLインジェクションなどの他の脆弱性に比べ、危険度は低く見積もられがちな脆弱性です。しかし油断していると大きな被害に繋がる足掛かりにされてしまう可能性もあるため、適切に対応していくことが大切になります。