OAuth2セキュリティ

ハブのこのブログエントリは、主に「キーマスター」の出現によるものです。これは、 蓄積 された をリンク して 転送する正当な理由です。





私たちのプログラムには、OAuth2仕様、弱点、脅威モデルの無料の改定 、認証付きハブトリックの0dayがあります。

OAuth2はただ

長くても正しい学習方法。

怠zyな人のために、私は自分の言葉で最も一般的で安全な、別名サーバーサイドとして承認コードフローを説明します 。



主な概念は、クライアント（ウェブサイト/オンラインゲーム/アプリ）、ユーザー（あなた）、プロバイダー（facebook / vkontakte / google）、コード（コード）およびトークン（access_token）です。



クライアントはユーザーを送信します-「リソースへのアクセスを許可してください」。 ユーザーはプロバイダーへのリンクをたどり、必要なものを探します-スコープパラメーター-[許可]をクリックします。 さらに、プロバイダーは、次のパラメーターを使用して、クライアントのドメイン上の指定されたredirect_uriにリダイレクトします。

code-プロバイダーのユーザーの識別子。クライアントはトークンを受信する必要があります

state-開始URLに渡されるのと同じ値。 CSRFに対する保護と利便性のために使用されます。



コードは、ユーザー（およびそれぞれユーザーエージェント）の値を表しません。 その助けを借りて、APIリクエストを行うことはできません。これは、トークンの取得という1つの目的にのみ必要です。

トークンを受信するために、クライアントは特定のエンドポイントを要求し、コードを受信したclient_id、client_secret、code、redirect_uriを渡します。したがって、プロバイダーはこれが正しいクライアントであり、同じユーザーのトークンを与えるコードであると確信します。 ご覧のとおり、ユーザー、ユーザーエージェント、クライアントスクリプトのいずれも実際のトークンを見ていません。 クライアントとプロバイダーだけが彼を知っています-理想的です。



さらに、トークンはAPIリクエストの作成に使用され、後で更新できます（このため、refresh_tokenはトークンとともに返されます）。

脅威モデルまたはあなたの考えを知っています

長くても正しい方法は、OAuthを安全に使用することです。

ここで私は注意します：



1.そして、私のサイトにつながるredirect_uriを置き換えて、このコードを自分で認証に使用するとどうなりますか？



すべてのredirect_uriはクライアントのドメイン上になければなりません。 多くの場合、別のプロバイダードメインが許可されます。 リンクはredirect_uri_mismatchを返します。



2. OK。しかし、クライアントのWebサイトでコードを統合する場所を見つけた場合はどうなりますか？ たぶん、site.com？url = http：//outsite.comの形式のオープンリダイレクトか、リファラーをマージするホットリンクされた画像でしょうか？



各コードは、発行されたredirect_uriに関連付けられており、トークンを受信するために、クライアントは「正しい」redirect_uriを送信します。 コードがclientsite.com/leak_refererに対して発行され、クライアントがトークンの受信時にclientsite.com/facebook_callbackを送信した場合、プロバイダーはトークンを提供しません。



3.正しいredirect_uriを渡すことで、何らかの方法でコードをマージすることは可能ですか？



いいえ、なぜなら クライアントの適切な実装は、コードを受け取った後すぐに別のページにリダイレクトする必要があります。そのため、コードはブラウザの履歴にも表示されません。

正しいredirect_uriのコードを取得できたとしても アクティブでなくなると、すでに使用されています。



4.正しいredirect_uriに対して発行されたソーシャルネットワーク上のアカウントのコードがあるとします。 Vasyaにこのリンクを訪問させるとどうなりますか？



この場合、クライアントのウェブサイトは、ソーシャルネットワークのアカウントがVasyaに属していると判断します。 そして接続します。 一般的なCSRFの発生を防ぐために、クライアントはセッション/ Cookieにランダムな状態値を保存し、リターンコールバックのコンプライアンスをチェックする必要があります。 ただし、これを行う人はほとんどいません（またはしませんでした）。

現実

FB返信攻撃

Facebook Connectは、従来のReplay攻撃に対して脆弱です。

ポイント3は、コードを1回使用した後でも、60〜80分以内に認証に使用できることを示しています。これは、トークンの標準のexpire_inです。 最も純粋な形でリプレイ攻撃。

サイトでXSSを見つけたとしましょう-このインジェクションのようなものは、document.referrerフレームを通して正しいredirect_uriのコードを取得するのに役立ちます。









レポートが完成し、すぐに修正します。 まあ、すぐに、約3か月、エンタープライズ

アカウントのハイジャック

たとえば、最も一般的な脆弱性はハブに存在します。詳細については以下を参照してください。 ポイント4に違反しています。

リクエストに状態が表示されている場合は、あきらめないでください。 digg.comがa12b6467c3fb385e237109502277ab26とheyman0day123123の違いを認識しなかったhabr

VK redirect_uri

実装はいくつかの古代の原稿に従って行われました-コードが発行されたredirect_uriの検証の欠如は、パラグラフ3の重大な違反です。

ご覧ください、 ここにリンクがありますので、恐れずにネットワークパネルを押してください 。 リクエストを参照してください？



リファラーがマージされ、コードがマージされました-正しいredirect_uriに関するVKontakte（リンクしている場合）を介してアカウントにログインするために使用できるようになりました。

レポートは1週間前に作成されましたが、生きている人やボットからの応答はありませんでした。

その他

暗黙的フローを使用している場合-つまり ユーザーからaccess_tokenを直接取得した場合、このトークンが現在のユーザーに属するという保証はありません。 彼は単に悪意のあるクライアントを介してそれを盗み、それを使用してあなたのサイトのあるユーザーのアカウントに入る可能性があります。

このトークンがclient_idに対して発行されているかどうかを必ず確認してください。



また、OAuth2は、ユーザーがscopeパラメーターの承認段階で要求した権限をユーザーに付与したことを保証しません。 彼は単にそれらを削除することができます -最後に、あなたが要求したものを許可したかどうかをコールバックで確認する必要があります。



サイトでXSSが見つかった場合、access_token-sを大量に盗む簡単な方法があります。 サイトがfacebookに使用する認証URLを取得し、response_type = codeをトークンに置き換えます。 このURLをフレームに挿入し、トークンがコールバックフォーム＃access_token = 123のリンクに戻るのを待って、トークンをカットしてマージします。 健康上のスパム！

ハブラーでの0day

同じエクスプロイトがfacebook / googleでも機能します。コードを使用せずにredirect_uriを取得するのは難しくなります。NoRedirect+ FFが必要です

したがって、VKのデモ。 おじさんが UPDを浴びない ： 脆弱性が修正されました 。



1. VKを接続しないでください。 ログインoauth.vk.com/authorize?response_type=code&client_id=3110645&redirect_uri=http%3A%2F%2Fhabrahabr.ru&scope=offline&display=page

2. habrahabr.ru/?code=CODEに戻りました

3.別のhabruiserにhabrahabr.ru/social/callback/vkontakte/?code=CODE&state=whogivesafuckaboutstateにアクセスします。リンク自体はスローできますが、imgやiframeなどで非表示にした方が良いでしょう。 ハブにログインしている場合、VKはハブアカウントに関連付けられています。

4. VKからhabraaccountにログインし、アバターをnayncatに変更します。

道徳

Vkontakte ：Supportの文字を無視するのをやめるか、開発者に来て、単なる人間と話をするよう依頼してください。 また、報奨金プログラムにも参加してください（皮肉：破られるリスクがあります）。

Habr ：しばらくキーマスターをオフにし、Cookie /セッションの値で「状態」を正しくチェックすることで脆弱性を修正することをお勧めします。



地獄への道は短い。 ボーリングトークン-OAuth2.a（ Charm-Provider ）を使用して、根本的に新しい標準の開発に参加できます 。 確かに、クッキーはありません。



エゴール・ ホマコフ （ @homakov ）＆ イシウルス #RT pls





UPD2：

Habrは脆弱性を閉じ、vkontakteはすべての新しいアプリケーションのredirect_uriチェックと古いアプリケーションの通知、facebookを追加しました。「許可コードはアクセストークンと1回だけ交換でき、作成後10分以内にアクセストークンと交換する必要があります」 「提供されたバグの詳細を確認した後、セキュリティチームは、2,000米ドルの報奨金を受け取る資格があると判断しました」と再度よく寄せます。 人々は報奨金vkの見通しについて推測します。