OAuthおよびOpenIDの「Covert Redirect」の脆弱性について誰かが説明できますか？
CNetが報告しています すべてのOpenIDおよびOAuthサイトは、「Covert Redirect」と呼ばれる攻撃に対して脆弱です。この攻撃とは何か、それはどのように機能し、最終的にはユーザー、どのようにリスクを軽減できますか？
これは、/ = OAuth 2.0）の脆弱性ではありません。この問題は、CNETと元のFinderによってひどく誇張され、誤解されています。
ここに一言で言えば：Webサイト（example.com）がオープンリダイレクトエンドポイントを実装している場合、つまり、ブラウザをanyにリダイレクトするURLを実装している-URLパラメータで指定されたURL-およびリダイレクトがURLパラメータを受信URLから送信リダイレクトURLにコピーすると、サードパーティがこれを悪用する可能性がありますあなたのWebサイトのアーティファクトさまざまな厄介な方法で。
最悪の場合：evil.comは元々Webサイト（example.com）を対象とした認証コードを取得でき、その認証コードを使用して認証プロバイダー（Google、Facebookなど）からユーザー情報を抽出できる可能性があります。 Webサイト上のユーザーのアカウントを制御することもできます。
Evil.comはそのアクセスコードを使用してユーザーのGoogleアカウントを制御できますか？いいえ、アクセスコードはあなたのサイトexample.comのために作成されており、そこでのみ機能します。
それは誰のせいですか？あなたの、あなたのサイトにオープンリダイレクトを実装するため。 GoogleやFacebookなどの不適切な実装のせいにしないでください。
サイトでリダイレクトを行う正当な使用例がいくつかあります。最大のものは、ユーザーが最初に要求した（サイト上の）Webページにログインした後にブラウザーをリダイレクトすることです。これはあなたのウェブサイトからあなたのドメインのあなたのウェブサイトのページにリダイレクトする必要があるだけです。
それを修正するには？リダイレクトエンドポイント（example.com/redirect？＆destination = ht.tp：//foo.com ...）で宛先URLを検証してもらいます。ドメイン内のサイトのページへのリダイレクトのみを許可します。
私のブログの詳細： http://dannythorpe.com/2014/05/02/tech-analysis-of-serious-security-flaw-in-oauth-openid-discovered/
更新： Facebookを使用すると、OAuthユーザーログイン。リダイレクトを開く問題が発生します。Facebookでアプリ定義を構成するときは、ドメイン固有のリダイレクトを入力してください提供されたリダイレクトフィールドのURL。Facebookでは、このフィールドを空白のままにすることができます。空白のままにすると、Facebook自体がWebサイトのユーザーログインの処理中にオープンリダイレクトとして機能します。
Facebookは、リダイレクトURLフィールドを空白のままにできないようにすることで、これを修正する必要があります。
他の人が述べたように、これは新しい考えではありません。 Eran Hammer（Oauth 1.0仕様の作成者の一人 Oauth 2.0委員から辞任 ）が良い概要を書いた）彼の説明には、派手なロゴや扇情的なメディアの報道はありませんでした。
http://hueniverse.com/2011/06/21/oauth-2-0-redirection-uri-validation/
これは、元のFinderがまとめて脆弱性を導き出したYoutubeビデオです： https://www.youtube.com/watch?v=HUE8VbbwUms 。
OpenIdとOAuthはどちらも、認証が完了して成功したときに、サードパーティのサイトがリダイレクトを指定できるようにするフィールドを提供します。たとえば、Good Readsにアクセスすると、 Facebookアカウント。GoodReadsはFacebookに「ユーザーが正常に認証されたら、リダイレクトして http://goodreads.com にリダイレクトします。」脆弱性は、これらのサードパーティサイトの一部リダイレクトをURL（ http://google.com/redirect?url=http://attacker.com ）で指定できるようにし、ユーザーをリダイレクトする前にそれらを検証しない場合があります。したがって、攻撃者は、Good Readsなどの有効なサイトに「Login with Facebook」リンクを作成し、リダイレクトURLを http://goodreads.com/redirect?url=http://attacker.comのように指定する可能性があります。 （Good Readsがこの種のリダイレクトを行ったと仮定した場合）、Facebookログインポップアップは、Good Reads（ユーザーがアクセスするための完全に通常のサイト）がFacebookで認証したいことを示しますが、認証してGood Readsにリダイレクトし直します。GoodReadsがリダイレクトURLを検証しない場合は、すぐに http://attacker.com にリダイレクトされます。
修正はサードパーティがリダイレクトを検証するためのものですが、それには時間がかかる場合があります。もう1つは、CNetは攻撃者がこの小さな交換を通じて情報を盗む可能性があると報告していますが、それが可能かどうかはよくわかりません。他の誰かがその問題についてコメントすることができます。しかし、ユーザーを悪いサイトに誘導することは、おそらく彼らにとって十分良いことです。
これは、サイトがOpenID資格情報を取得できる中間者攻撃の一種です。これは、openIDのソース（facebook、googleなど）がopenIDクエリの送信時に十分なチェックを実行しないために機能します。
ユーザーができることは何もありません。OathとopenIDの使用には非常に注意が必要です。 openIDの使用を想定していないサイトがopenIDウィンドウをポップアップする場合は、許可しないでください。 openIDの認証情報が取得された疑いがある場合は、認証ソース（facebook、googleなど）にアクセスし、できるだけ早く変更します。
http://tetraph.com/covert_redirect/
ウェブサイトから、
Covert Redirectは、パラメーターを受け取り、検証なしでユーザーをパラメーター値にリダイレクトするアプリケーションです。これは多くの場合、パートナーに対するWebサイトの自信過剰の結果です。
別の言い方をすると、パートナーのドメインに属するリダイレクトされたURLの十分な検証がないため、秘密のリダイレクトの脆弱性が存在します。