web-dev-qa-db-ja.com

OAuth 2認証コードフローは、混乱した代理問題に対して脆弱ですか？

混乱した代理問題（別名「悪魔がプラダを身に着けている」）は、認証にプロトコルが使用されたときに発生するOAuth 2の脆弱性です。基本的に、悪意のあるクライアントがユーザーのトークンを取得し、これを2番目のクライアントに提示します。2番目のクライアントが認証の証拠としてトークンを受け入れる場合、悪意のあるクライアントは別のクライアントに対してユーザーとして自分自身を認証できます。

http://blog.intothesymmetry.com/2013/05/oauth-2-attacks-introducing-devil-wears.html や OAuth implicitなどのこの脆弱性のほとんどの説明ではフローと混乱した代理問題 、これは暗黙のフローでのみ機能することをお勧めします。

ただし、認証コードフローでも同じ問題が発生しませんか？悪意のあるクライアントがユーザーの認証コードを取得し、その認証コードを2番目のクライアントに提供できるようです。これで、2番目のクライアントは承認サーバーにバックチャネル要求を行い、完了時に2番目のクライアントは悪意のあるクライアントではなくユーザーと通信していると信じます。

この分析は正しいですか？

authorizationoauth2confused-deputy
1
Matthijs Melissen

Authentication Code許可フローでは、認証サーバーは、2番目のクライアントとは異なるクライアントに提供された認証コードを把握できます。

認証コードを取得するには、以下のサンプルリクエストが悪意のあるクライアントから発行されます。

GET /authorize?response_type=code&client_id=<malicious client ID>&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

認証サーバーは、認証コード要求が成功した結果として、認証コードとクライアントIDのマッピングを保持することに注意してください。

これで、悪意のあるクライアントがこの認証コードを2番目のクライアントのリダイレクトURIに提供し、2番目のクライアントが認証トークンを要求します。以下のサンプル：

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

クライアントIDとシークレットはAuthorizationヘッダーにエンコードされていることに注意してください。その結果、認証サーバーがこのような情報を処理するときに、リクエストのクライアントIDが認証コードのクライアントIDと一致するかどうかを確認できます。最初に割り当てられました。この場合、一致はありません。その結果、認証サーバーはリクエストに応答してアクセストークンを許可しません。

つまり、バックエンドで認証サーバーによって実行されるクライアントIDのチェックにより、認証コードと引き換えに返されるすべてのトークンがアプリケーションに対して発行されたことが保証されます。

1
Chen Xie