OAuth2セキュリティとFacebook Connectの脆弱性

これは私の見事な最初の記事の続編です。



すべてのWeb開発者は、Facebook接続またはVKontakteのログインまたはTwitter経由の認証に遭遇したに違いありません。 これらはすべて、基本的にOAuth1 / 2に基づいています。



私の意見では、私たちは皆間違った方向に進んだと思います。 OAuthは地獄への道です (ところで、Eran Hammerは現在oauth-ozの置き換えに取り組んでいます)。



この記事では、攻撃モデルについては詳しく説明しませんが、すぐに使用を開始できる特定の脆弱性については再説明します。



画像





ログイン時のCSRF



他の状況では、このような取るに足らない、状態は変化しますが、機能に関するCSRFは価値がないと思います。 しかし、リダイレクトに基づいて構築されたプロトコルになるとすぐに...事実は、99%の場合、ユーザーの操作なしでGET自体/ユーザー/接続/ Facebookをダウンロードしてプロセス自体を開始することで、サイト<= Facebook接続プロセスを開始できることです。

Facebookユーザー(プロバイダー)をアカウントにログインし、このエンドポイントを接続用にダウンロードします。これにより、攻撃側のアカウントがクライアントの被害者のアカウントに自動的に接続され、被害者のアカウントに自分でログインします。

Facebookはリファラーチェックによってのみ保護されます。













これは、 最も一般的な間違い (状態チェックではない)の新しい化身であり、より高いレベルでのみです。 コードでコールバックをスローするのではなく、Facebookに強制ログインによってアカウントからコードを強制的に返します。 FBは、fbのさまざまな既存のプラグインとの互換性を損なうため、これを修正することを拒否しました。 VK.comも脆弱です(これらの人は報告する場所がありません。何らかの場所です。安物の宝石店でさえセキュリティに対してより深刻なアプローチを持っています)。 このバグは、omniauth、django-social-auth、php-sdkなどを備えたサイトで使用できます。 バグ修正-アドレスのロード/接続時にcsrfトークンを確認する必要があります。



アカウミガメのアイデアはOAuthに影を落とします-Cookieを強制的に使用しても、被害者のCookieを完全に置き換えて任意のプロバイダーにログオンできます。 これは概念的なエラーであり、決して修正することはできません。



signed_request



CPはclient_secretを使用して署名された要求であり、作成されます...理由は明らかではありません。 事実は、これは本質的に同じコードフローであり、コードのみが#フラグメントで送信され、redirect_uri = ""でリリースされるということです。 したがって、302リダイレクトを介してsigned_requestを盗む場合、クライアントのサイトでCPの所有者としてログインするためにそれを使用できます(Cookie fbsr_CLIENT_ID = SRを置くだけです)。



簡単に言えば、サイトにFacebook JS SDKがあり、オープンリダイレクト(ドメインまたはサブドメイン上)が見つかった場合-被害者のSRをマージしてアカウントを盗むことができます。 そして、これは再び修正されません。



OAuth1 Paypalコミット



別のWontFix。 ペイパルでは、エクスプレスチェックアウトフローを実行する前に、すべてのパラメーターを送信してrequest_tokenを取得し、paypal?Token = request_tokenをアップロードする必要があります。 実際には、このトークンを自分用に発行し、フィッシングで被害者のブラウザにこのURLをダウンロードし、このトークンの代金を支払うように説得して(支払いは実際にクライアントに送られます)、自分でコールバックすることができますか?トークン=トークンと支払ったすべてのお金を得る被害者はすでに彼のアカウントにあります。 これをnamecheapでテストしました。



これは、OAuth1のセッション固定の完全なコピーです。 すべてのプロバイダーによって開かれたとき、パッチへの接続をオフにしました。 私たちの場合、Paypalは耳さえ動かしませんでした。 それらは再び脆弱であり、クライアントサイトではなくクライアントサイトです。



おわりに



ソーシャルネットワーク経由のログインを使用しないことを強くお勧めします。 これを強制的に実装する場合は、最大数のチェックを規定し、クライアント設定で静的コールバックを設定してみてください(強化-攻撃対象領域を減らします)。 上記のバグにより、soundcloud、foursquare、songkick、airbnb、およびソーシャルログインを使用する数十のスタートアップのアカウントをハイジャックするエクスプロイトが見つかりました。



PS Yandexで、報奨金はアカウントを盗む方法を書きましたが、あまり興味がないので、ここにコピーします。



1)Facebookでセッションを修正する



2)YandexでURLを呼び出す

ソーシャル。



3)攻撃者のfbをパスポートに自動的に接続しますが、幸いなことに(残念ながら)まだそれを介して認証を確認する必要があります。 ちょっとしたソーシャルエンジニアリング、船

passport.yandex.ru/passport?mode=authentication&retpath=https%3A%2F%2Fsocial.yandex.ru%2Fupdate%3Fprofile_id%3D23177612%26allow_auth%3D1

ご覧のとおり、Facebookやアカウントに関する言葉はありません。パスワードを入力するだけで、ユーザーは喜んでそれを行います(サイドバグ。おそらくパスワードを要求する理由を説明する価値はありますが、あなたは決して知りません)



4)攻撃者fbを介してYandexから直接ログインし、facebookを接続し、メールとcookieを盗む-完全な犯罪

英語の元の投稿。



All Articles