0

ほぼすべてのフォーラムで、特に oauth2 と jwt を使用した Web アプリケーションのセキュリティ (モバイル アプリを考慮していない) について多くの議論が行われています。誰もがコメント/回答をこれとあれ、何とか..何とか..何とかセキュリティトークンについて入れました（「2016」の終わりまでに、貴重なWebのほとんどすべてがステートレスになった可能性があると仮定します）。真剣に、それがそれほど簡単かどうかはわかりませんが、攻撃者がユーザーのクライアント側の web アプリ access_token と refresh_token を盗むのはとてもリラックスして簡単であるかのように、誰もが架空の攻撃者に対して回答を書いていることがわかりました。攻撃者がクライアント側で access_token と refresh_token を発行した Web アプリを実際に侵害する可能性のあるさまざまな方法は何ですか? この種の侵害は、Web アプリを使用するユーザーにも依存しますか? 攻撃者は、クライアントと認可サーバー間の通信をどのくらい簡単に盗聴できるでしょうか? 誰かがショーケースしたい場合、オープンなコード例は高く評価されます。Web アプリのセキュリティについての面倒な議論ではなく、的を射た回答を求めます。たまたまQuoraのような質問だったらすみません。

4

1 に答える 1

1

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

数年前、OAuth2 がドラフトにすぎなかったとき、その仕様の主な貢献者の 1 人が、そのトピックに関する興味深いブログ投稿を書きました。彼の言うとおりです。このフレームワーク プロトコルは、すぐに利用できる多くの可能性を提供して、クライアントになりすましてユーザー リソースにアクセスしたり、管理者リクエストを含む有効なリクエストを送信したりできます。

主な理由は、RFC6749が TLS 接続に依存していることを明確に示しているためです。アクセス トークンがエクスポートされない限り、攻撃がユーザーに依存することはほとんどありません。中間者、悪意のあるモバイル アプリ、リバース エンジニアリング、ブルート フォースなど、アクセス トークンを取得する方法の一部を利用できます。すべてのタイプの攻撃の完全なリストを取得するのは困難です。

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

次の RFC またはドラフトを読むことをお勧めします。

さらに、 (私の視点から) トークンを TLS 接続にバインドするための主要な改善であるトークン バインディング ドラフトにも興味があるかもしれません。つまり、アクセス トークンが侵害された (または意図的にエクスポートされた) 場合でも、TLS 接続が異なるため使用できません。

OAuth2 のセキュリティに関連するその他のドラフトは、IETF OAuth2 ワーキング グループのページで入手できます (署名されたリクエスト、クロージング リダイレクター、X.509 クライアント認証などを参照)。

于 2016-10-13T08:00:31.990 に答える