新たなセキュリティ上の欠陥が影響を及ぼしているとの息の詰まる報告OpenIDそしてOAuth-- Facebook、Microsoft、Google、LinkedIn などのサービスの ID ログインを強化するテクノロジー -- が金曜日のニュースになりました。 「Covert Redirect」と呼ばれるこの欠陥により、悪意のあるサイトやリンクがユーザーのログイン情報を取得できる可能性があります。
Covert Redirect の発表はまさに次のとおりです。ハートブリードのマーケティングマニュアル、両方付属洗練されたウェブサイトそして派手なロゴ。 OAuth の普及と潜在的なセキュリティ脅威に対する意識の高まりと相まって、Covert Redirect は確かに悪いもののように思えます。
すでに見えています報道機関これを次の大きな Web セキュリティ危機として報告します。
幸いなことに、Covert Redirect は次の Heartbleed ではありません。実際、私たちが確認できる限り、Covert Redirect の「欠陥」は新しいものではありません。さらに、Covert Redirect を OAuth 2.0 および OpenID の脆弱性として分類することは誤りです。
これは、潜在的な問題が存在しないということではありません。問題は存在します。その仕組みについては後で説明します。ただし、これは新しい発見ではなく、LinkedIn や Facebook などの企業が問題を抱えていることを理解することが重要です。そしてGoogleは潜在的な懸念をすでに認識している。
OAuth と OpenID 101
OAuth認可のためのオープンスタンダードです。これは、ユーザーが Google、Facebook、Microsoft、Twitter などのサイトの既存の ID を使用して他のサービスにサインインまたはサインアップする方法として設計されています。 OpenID は、シングル サインオン (SSO) にも使用される同様のプロトコルです。
これらのプロトコルは、企業が複数の新しいアカウントを作成することなく、複数のサービスに簡単にサインインできるようにするために使用されます。 Twitter アカウントを使用して Flipboard にサインアップするか、Facebook アカウントを使用して Pinterest にサインアップする場合、OAuth は舞台裏ですべてを機能させるテクノロジーです。 OAuth 2.0 は OAuth プロトコルの次のバージョンであり、まだ開発中です。
OAuth 2.0 は実際には、設定されたプロトコルというよりはフレームワークであることは注目に値します。つまり、アイデンティティ プロバイダーは、使用したいプロトコルの機能を選択し、独自のニーズに合わせてさらにカスタマイズできるということです。
これは、開発者がソフトウェアに追加できるライブラリのセットである OpenSSL とは大きく異なります。これは、OAuth 2.0 ライブラリが存在しないということではなく、実際に存在します。しかし、主要なサービス プロバイダーのほとんどは独自の変更と実装を行っています。
だからこそ、Covert Redirect の欠陥を OAuth 2.0 の脆弱性として分類するのは無責任です。この欠陥は OAuth 2.0 仕様内にあるのではなく、Facebook がその仕様を独自のシステムに実装する方法にあります。
既知の問題を再浮上させる
シンガポールの南洋理工大学の博士課程の学生である Wang Jing は、Covert Redirect を「発見」し、Web サイトとロゴを作成したとされています。の動画も公開したYouTube で悪用が行われている。
の上彼のブログで、リダイレクトパラメータを使用して「Facebook OAuth 2.0をハッキングする新しい方法を発見した」と説明しています。つまり、Wang 氏は、悪意のあるリンクから Facebook ログインを表示させることができることを示すことに成功しました。
派手なロゴに騙されないでください。この脅威はあなたが思っているほど悪くないし、新しいものでもありません。 クレジット: 王京
たとえば、別のサービスに似たフィッシング サイト (おそらく Facebook ログインを使用するサイト) にアクセスした場合、Facebook ログイン ボタンをクリックすると、実際にその詳細が攻撃者に送信されます。
しかし、これは新しい認識ではありません。 Jing の発見は、ある方法に非常に似ている (または同一) ようです。エゴール・ホマコフ2013 年 3 月に議論されました。
ホマコフ氏はセキュリティコンサルタントで、過去にFacebookのセキュリティバグを報告したことがある。ニル・ゴールドシュラガー（彼もまた、Facebookのセキュリティ上の欠陥を発見する）、OAuth 仕様の redirect_uri パラメータを改ざんすることで Facebook ログインがどのようにハイジャックされる可能性があるかを概説しました。
おそらく、Facebook が Graph API を使用して OAuth 2.0 と統合する方法により、これが可能になります。
開発者アレックス・ビルビーOAuth 2.0 とそれを最適に実装する方法について頻繁に書いています。昨年、OAuth 関連のハイジャックが相次ぎ、フレームワーク自体が安全ではないという議論が巻き起こりました。それは正確ではありません。問題は、フレームワーク自体ではなく、特定の企業が OAuth の実装をどのように選択するかに起因するとビルビー氏は説明します。
Homakov の redirect_uri 攻撃の場合、ビルビーは指摘したこれらのタイプのフィッシング リダイレクトの可能性は、OAuth 2.0 仕様自体で概説されている可能性があるということです。
実際には、セクション全体Homakov (と Jing) が詳述した内容を正確に概説する OAuth 2.0 脅威モデル仕様の一部です。
認可サーバーがクライアントにリダイレクト URI の一部のみの登録を許可している場合、攻撃者はクライアントが操作するオープン リダイレクターを使用して、認可サーバーの検証には合格するが、認可コードまたはアクセス トークンをサーバーに送信するリダイレクト URI を構築する可能性があります。エンドポイントは攻撃者の制御下にあります。
解決策は、すべてのクライアント (アプリ) にリダイレクト URI のホワイトリスト、動的 URI からの攻撃を防ぐため。
では、なぜ Facebook は今これをやらないのでしょうか?ビルビーには理論がある:
Facebook でこれが起こった理由の一部は、2010 年に Graph API を立ち上げたときに、OAuth 2.0 仕様のドラフト 5 でセキュリティを確保していたからではないかと私は考えています。仕様が変更された時点で 27 のドラフトがあり、クライアントはすでに簡単に更新できない特定のパラメータでハードコーディングされていたため、攻撃に使用された上記のパラメータが動的および非標準パラメータを受け入れることを許可する選択をしなければなりませんでした。価値観。
言い換えれば、Facebook が最初に Facebook ログイン機能をリリースしたとき、OAuth 2.0 の非常に初期のドラフト バージョンに依存していました。登録されたリダイレクト URI やホワイトリスト チェックの要求などの変更は、フレームワークの実装が存在した後に行われました。
今その実装を更新することは、潜在的な既存のクライアント実装を大量に破壊することを意味します。
それは何と一致しますかJingに対するFacebookの反応。 Jing 氏によると、Facebook は「OAuth 2.0 に関連するリスクを理解している。しかし、プラットフォーム上のすべてのアプリケーションにホワイトリストの使用を強制する以外に、[脆弱性の修正は] 短期間で達成できるものではない」と告げられたという。学期"
Facebook を使用する Web サイトとアプリはリダイレクトに URI ホワイトリストを利用できることに注意してください。これは必須ではありません。既存のサイトやアプリケーションは、Facebook アプリに redirect_URI を登録することで、悪意のあるサイトがこの種の攻撃でログイン ID を使用しようとするのを防ぐことができます。
本当の危険とは何でしょうか？
現在、状況が適切であれば、フィッシング サイトを使用して Facebook のログイン資格情報をハイジャックすることが可能です。 OAuth 2.0 の実装によっては、他のサービスでもこれが可能になる可能性があります。
ただし、最初にこの脆弱性を悪用するには、ユーザーはリンクをクリックするか、悪意のある Web サイトにアクセスする必要があることに注意することが重要です。また、ユーザーは悪意のあるリンクをクリックするだけでなく、Facebook のログイン ボタンをクリックして、ログインと情報の公開を許可することに同意する必要があります。
そのため、この種の脅威は、Heartbleed などとははるかに異なるレベルにあります。セキュリティ上の欠陥ほど深刻ではないMicrosoft がパッチを適用したばかりInternet Explorerで。
悪意のある Web サイトに情報が提供されることを避けるために、ユーザーは信頼できるサイト経由でのみ Facebook またはその他のサービスにログインする必要があります。サイトが大ざっぱに見える場合は、やめてください。ここでは、標準的なフィッシング対策慣行が適用されます。
もちろん、Facebookができるだけ早く仕様を更新する必要があるのは言うまでもありません。たとえそれが一部のサイトやアプリを破壊することを意味するとしても、これはあまりにも長い間存在してきた欠陥です。
先月、LinkedIn は開発者全員に次のことを要求しました。リダイレクト URL を登録するための OAuth 2。
ハートブリード効果
私にとって、Covert Redirect の最も魅力的な側面は、Heartbleed の「成功」を模倣しようとする方法です。
Mashable 編集長兼主任特派員ランス・ウラノフとして先月指摘した, Heartbleed はまさに、最初のインターネット セキュリティのスーパースターです。
Heartbleed の悪名は、堅実な名前、読みやすい Web サイト、魅力的なロゴから来ています。難解な命名規則や理解しにくいセキュリティ情報を伴うほとんどのセキュリティ脆弱性とは異なり、Heartbleed には独自のアイデンティティと独自のブランドがありました。
Heartbleed はまさに、強力なブランド アイデンティティが必要なタイプのセキュリティ欠陥でした。もしこれが他のウイルス警告と同じように設定されていたなら、欠陥の重要性、潜在的な影響、深刻さが見落とされていた可能性があります。現状では、Heartbleed から得られる最も優れた点の 1 つは、全体的なセキュリティ意識を高める上でそれが果たした役割です。
これが、私が Covert Redirect などのキャンペーンに悩まされる理由です。はい、潜在的な脅威は現実です。しかし、これは「ハートブリード治療」に値する種類の欠陥ではありません。この欠陥は新しいものではないだけでなく、認可仕様の実装を担当する関係者にはよく知られています。
Heartbleed のブランディングとアイデンティティが機能しているのは、バグにロゴ、名前、ウェブサイトを与えるというコンセプトの背後にある斬新さのおかげでもあります。それがあまりにも頻繁に起こると、ユーザーはセキュリティに関する発表を無視し、本当に問題のあるものを無視するようになるのではないかと心配しています。
Heartbleed から 1 か月後、多くのユーザーはセキュリティ上の脅威に対して厳重な警戒を払っています。それは良いことだ。私たちは皆、存在する潜在的な危険をもっと認識し、警戒する必要があります。しかし、それはすべてのバグを終末のように扱う必要があるという意味ではありません。たとえロゴが入っていたとしても。
ボーナス: Heartbleed の脅威の説明