オープンリダイレクト脆弱性

リダイレクトの定義

リダイレクトとは、ウェブサイトやウェブアプリが裏側の仕組みを使い、エンドユーザーがアクセスするURLを変更する処理です。HTTPヘッダーの転送やJavaScriptの利用など、いくつかの方法があります。

十分な管理や保護がされていない場合、リダイレクトは攻撃対象となりやすく、悪意ある攻撃者が利用してユーザーやクライアント、訪問者を誤ったサイトに誘導する恐れがあります。 

‍

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

これは、クライアント側で生成されるリダイレクトのうち、正しくないか適切にフィルタリングされていないものを指します。このようなリダイレクトは安全ではなく、攻撃者に利用される余地があります。

安全なリダイレクトとそうでないリダイレクトにはそれぞれ特徴があります。例えば、暗号化されたサイトがクライアントを常に固定のURLへリダイレクトするのは安全な方法とされますが、クライアントにリダイレクト先を指定させる場合は安全とは言えません。このようなリダイレクトはオープンリダイレクトと呼ばれます。

また、ユーザー定義のパラメータを利用している場合は安全とされますが、入力の検証やフィルタリングが行われていないと、攻撃者が悪意ある内容を挿入する可能性があります。

まとめると、動的リダイレクトを利用する際は、初めから信頼できないと判断し、強固なセキュリティ対策を講じる必要があります。対策が不十分な場合、攻撃者がリダイレクト先を改ざんされた危険なサイトへ変更する恐れがあります。

分類に関しては、オープンリダイレクトはOWASP Top 10 2013でA10に位置付けられており、Netsparkerでは中程度の危険性があると評価されています。 

オープンリダイレクト脆弱性の例を用いて、その概念を理解してみましょう。

例えば、test.comというドメインを所有しているとします。貴社の利用者を狙う攻撃者は、以下のようなURLを生成する可能性があります。

https://test.com/redirect.php?url=http://attacker.com 

このURLはフィッシング攻撃に利用され、最初にtest.comが含まれているため、利用者に正規のサイトであると誤認させる狙いがあります。

サイトにオープンリダイレクトの問題が存在すれば、攻撃者はこのURLを容易に実装することができます。 

以下は、その実例を示すコードです。 

$redirect = $_GET['url']; header("Location: " . $redirect);

‍

種類

1. ヘッダー方式

JavaScriptを使用しなくても発生する可能性があります。攻撃者はHTTPのLocationヘッダーを利用し、例えば以下のような問題を引き起こします：

• リンク訪問時のリダイレクト
• レスポンスヘッダーであるため、新たに生成されたリソースの位置情報が漏洩する恐れがある

このように、URL内に悪意ある内容が含まれていても利用者が気付かない場合、深刻な結果を招く可能性があります。

2. JavaScript方式

サーバ側の制限の代わりにJSによるチェックや検証のみを行うと、攻撃者がクライアント側で無効化できるため、ページがリダイレクト攻撃に対して脆弱になります。

もし攻撃者がJS方式のリダイレクトを成功させれば、悪用の可能性は無限大となります。そのため、オープンリダイレクトを利用したフィッシング攻撃では、しばしばJavaScriptが用いられます。

攻撃者がオープンリダイレクトを利用する方法

以下のように、複数の悪用方法が考えられます：

• 利用者を危険・悪質なサイトに誘導する

一般的な手法です。フィッシング詐欺で見られる手法の一例であり、攻撃者は脆弱なブラウザやCSRF攻撃に弱いページを利用することが多いです。

信頼できるリソースからそのような内容が提供されているように見えると、利用者は罠に陥ります。この手法のもっとも一般的な例は、改ざんされた銀行や金融サービスのサイトが訪問者をCSRF攻撃用のページへリダイレクトするケースです。

• クロスサイトスクリプティング (XSS)

オープンリダイレクトを利用したXSS攻撃を実行するには、HTTP以外のプロトコルを使用する必要があります。直接使用すると検出・ブロックされるため、攻撃者はJavaScriptやDOMオブジェクトを用いて攻撃を行います。

• フィッシング攻撃

信頼性の高いサイトであっても、オープンリダイレクトのエンドポイントが存在すると、攻撃者はフィッシング攻撃の足がかりとして利用することがあります。これにより、正規のサイトに悪意あるリンクを挿入したり、改ざんされたURLを含むフィッシングメールを送信したりすることが可能となります。見た目が本物に似せてあるため、利用者が誤った危険なURLに誘導される恐れがあります。

攻撃者は本物のサイトに見せかけるために細工し、非常に長いエンコード済みパラメータを使用するため、識別が難しくなることが多いです。このため、フィッシング攻撃は成功しやすく、認証フローが確立されたサイトであっても被害に遭う可能性があります。

• サーバーサイドリクエストフォージェリ

これは内部ネットワークを狙った攻撃で、内部ホストでリダイレクトが発生した場合にのみ実現可能です。SSRFはパストラバーサルと組み合わせることで、攻撃者が内部にアクセスする恐れがあります。

• トークン窃盗シナリオ

オープンリダイレクトの忘れてはならない利用例の一つに、ユーザートークンの窃盗があります。SSOを採用したアプリでオープンリダイレクトが存在すると、攻撃者が認証済み利用者になりすまし、セッションハイジャックなどの攻撃を行う可能性があります。 

‍

オープンリダイレクトの防止策

ユーザー入力の検証不足が、オープンリダイレクトが悪用される主な原因です。ここで問題となるのはURLのクエリ文字列です。この脆弱性の発生と影響を減らすため、以下の防止策が有効です。

• URL内でユーザー提供のデータは最小限に留め、利用する際には適切なサニタイズを行うこと。詳細はOWASPのCheat Sheetを参照してください。 
• 許可されたリダイレクト先のホワイトリストを作成し、それ以外は既定のURLへ誘導する方法が効果的です。 
• 各リダイレクト先に固有のIDを設定する方法も有効です。これにより、URL内にユーザーが操作可能な名称が含まれなくなります。
• APIセキュリティの専門家は、Referrer-Policyヘッダーを適切に設定し、参照元URLの露出を抑えることを推奨しています。 
• 転送・リダイレクトの利用は、必要最小限にとどめ、十分に安全なものにする必要があります。 
• ユーザー生成のURLを受け入れる場合は、短いURL名またはトークンを求め、その属性をサーバ側で完全に管理するのが賢明です。
• Wallarmのサイバーセキュリティ製品、API Security Platform、GoTestAPIを試してみるのも一案です。