攻撃者がaccess_tokenおよび/またはrefresh_tokenを侵害する可能性のあるさまざまな方法は何ですか？

Question

oauth2とjwtを使って、Webアプリケーションのセキュリティ（モバイルアプリを考慮しない）に関するほとんどのフォーラムで多くの議論があります。セキュリティトークンについては、皆さんのコメント/答えを、blah..blah..blahに入れてください（ほとんどの貴重なウェブが、この「2016年末近くに無国籍になったかもしれない」と仮定しています）。真剣にも、私はそれがとても簡単かどうかは分かりません。ユーザーのクライアント側のWebアプリケーションaccess_tokenとrefresh_tokenを盗むのは、あまりにもリラックスして攻撃者が簡単なように、攻撃者が実際にあなたのWebアプリケーションを侵害し、クライアント側でaccess_tokenとrefresh_tokenを発行するさまざまな可能性のある方法は何ですか？このような妥協は、Webアプリケーションを使用するユーザーにも左右されますか？攻撃者がクライアントと認証サーバーとの間の通信をいかに簡単に盗聴する可能性がありますか？誰かがショーケースを望むならば、オープンなコード例は高く評価されます。ウェブアプリケーションのセキュリティについての議論に疲れさせるのではなく、その答えを求めている。私はそれがQuoraのような質問になったのであれば謝りたい。

Answer 1

一般に、OAuth2のセキュリティについては、多くの正当な質問があります。

数年前、OAuth2が草稿であったとき、その仕様の主な貢献者の1人がそのトピックにan interesting blog postを書きました。 そして彼は正しい：このフレームワークプロトコルは、すぐにクライアントを偽装し、ユーザーリソースにアクセスしたり、管理要求を含む有効な要求を送信したりする可能性が非常に高い。

主な理由は、RFC6749がTLS接続に依存していることを明確に示していることです。アクセストークンがエクスポートされない限り、攻撃はユーザーに依存することはまれです。悪意のあるモバイルアプリ、リバースエンジニアリング、ブルートフォース...アクセストークンを取得するためのいくつかの方法があります。あらゆる種類の攻撃の網羅的なリストを得るのは難しいです。

ただし、フレームワークプロトコルであるため、追加のセキュリティ機能の実装を妨げるものはありません。 そのため、the IETF OAuth2 Working Groupは、すべての利害関係者（クライアント、認証サーバー、リソースサーバー）とそれらの間の通信を保護するためのいくつかの非常に興味深い機能拡張に取り組んでいます。

私は、次のRFCや草稿を読んですることをお勧めいたします：

• RFC6819：OAuthのた​​めの追加のセキュリティの考慮事項を示します。
• RFC7800、POP Key DistributionとJWTまたはSAML2アサーションに基づいて、新たなクライアント認証方法を実装したトークン失効
• RFC7521、RFC7521とRFC7521ためabandonned MAC access tokens
• RFC7009を交換しようとPOP Architecture
• RFC7636：コードのための証明キー悪意のあるモバイルアプリケーションが認証コードを取得してからアクセストークンを受け取らないようにするExchange。

さらに、（私のPOVから）token binding draftに興味があるかもしれません。これはトークンをTLS接続にバインドするので大きな改善点です。言い換えれば、アクセストークンが侵害されている（または意図的にエクスポートされている）場合でも、TLS接続が異なるため使用できません。OAuth2のセキュリティに関連する

より多くのドラフトは（... signed requests、closing redirectors、X.509 Client authenticationを参照してください）the IETF OAuth2 Working Groupページで入手できます。