クライアントクレデンシャルとOWINミドルウェアを使用する際の脆弱性OAuth

Question

私はMVCアプリケーションでOAuth2 client_credentialsフローを実装しました。このシナリオでは、MVCアプリケーションは実際にはリソースです。このフローは主にAPIアクセスに使用されていたため、この特定の使用例のサンプルを確保するのは非常に困難でしたが、それでもやっていました。
私が気づいていない可能性のある脆弱性に関する情報を求めるために、実装の詳細をあなたと共有したいと思います。私は決してセキュリティ専門家ではありません。それが私をここに連れてきました。
.NET Framework 4.5.2では、Microsoft.Owinライブラリv3.0.1を使用しました。私は、この種のもの（.NET CoreやIdentityServer4など）を設定するための新しい方法があることを知っていますが、この特定のユースケースで実行可能なサンプルを見つけるのは難しいと言いました。以下のスタートアップコードと

public class ApplicationOAuthProvider : OAuthAuthorizationServerProvider 
{ 
    private ClientService clientService; 

    public ApplicationOAuthProvider() 
    { 
     this.clientService = new ClientService(); 
    } 

    public override Task ValidateClientAuthentication(OAuthValidateClientAuthenticationContext context) 
    { 
     string clientId; 
     string clientSecret; 
     context.TryGetFormCredentials(out clientId, out clientSecret); 

     if (clientId == "XXXX" && clientSecret == "XXXXX") 
     { 
      context.Validated(clientId); 
     } 

     return base.ValidateClientAuthentication(context); 
    } 

    public override Task GrantClientCredentials(OAuthGrantClientCredentialsContext context) 
    { 
     var client = clientService.GetClient(context.ClientId); 
     var oAuthIdentity = new ClaimsIdentity(context.Options.AuthenticationType); 
     oAuthIdentity.AddClaim(new Claim(ClaimTypes.Name, client.ClientName)); 
     var ticket = new AuthenticationTicket(oAuthIdentity, new AuthenticationProperties()); 
     context.Validated(ticket); 
     //context.OwinContext.Response.Headers.Add("Access-Control-All‌​ow-Origin", new[] { "*" }); 
     return base.GrantClientCredentials(context); 
    } 

：
私はプロバイダを実装

public partial class Startup 
{ 
    public static OAuthAuthorizationServerOptions OAuthOptions { get; private set; } 

    static Startup() 
    { 
     OAuthOptions = new OAuthAuthorizationServerOptions 
     { 
      TokenEndpointPath = new PathString("/Token"), 
      Provider = new ApplicationOAuthProvider(), 
      AccessTokenExpireTimeSpan = TimeSpan.FromMinutes(60), 
      //AllowInsecureHttp = true, 
      AuthenticationMode = AuthenticationMode.Active, 

     }; 
    } 

    public void ConfigureAuth(IAppBuilder app) 
    { 
     app.UseCors(CorsOptions.AllowAll) 
      .UseOAuthBearerTokens(OAuthOptions); 
     //app.UseOAuthBearerTokens(OAuthOptions); 
    } 
} 

public partial class Startup 
{ 
    public void Configuration(IAppBuilder app) 
    { 
     app.UseCors(Microsoft.Owin.Cors.CorsOptions.AllowAll); 

     ConfigureAuth(app); 
    } 
}  

、その後も、ウェブサイトでのクライアントアプリケーションを作成し、最終的にリソース（MVCアプリ）へのアクセスを得ました。リソースにはユーザーがないため、ログイン画面はありません。リソース（現在）にトークンエンドポイントがあります。クライアントアプリケーションは、トークンエンドポイントに対して資格情報を要求し、（認証された後に）そのトークンをリソースへの後続の要求で使用します。
このトークンを使用してアクセスするには2通りの方法があります。

• リクエストヘッダーにアクセストークンを含めます。
  は、クライアント・アプリケーションとサーバ間のすべての通信を想定すると、セキュアチャネル（HTTPS）と、クライアント上で起こっている：OR
• は、私の質問は、このシナリオに脆弱性に関するしているフォームパラメータ

としてアクセストークンを含めますアプリは安全な方法でクレデンシャルを維持することができますが、アクセストークンを取得または傍受する可能性は何ですか？または、このフローに含まれるメソッド（または別のOAuthフロー）にクライアント検証も含まれていますか？私はクライアントがすでにclient_id/client_secretで認証されていることを認識していますが、私が検証について尋ねるとき、私は要求の起点について尋ねています（検証方法には偽装可能なもの悪意のあるユーザーによる）。
私は欠席している可能性があることを含めるべきであることを確認するための追加のステップがありますか？そこに多くの情報があり、徹底的に捜索するためでしたが、私はすべてのことをしっかりと理解していますこれまで読んだことがあります。
私が見逃した追加の確認ステップがある場合、それはどのようにこの（client_credentials）フローに適合しますか？

おかげで、 キャリー

Answer 1

は、私がアクセスを得るために、このトークンを使用しての2種類の方法を見つけました。

• リクエストヘッダーにアクセストークンを含めます。使用してGETメソッド：OR
• これはあなたのアクセストークンが（そのため、あなたはまた、アクセストークンを送信するための第三の方法を使用することができますタイプベアラトークンであることを意味フォームパラメータ

としてアクセストークンを含めますクエリパラメータ付き）。

アクセストークンを取得または傍受する可能性はありますか？

または、このフローに含まれるメソッド（または別のOAuthフロー） には、クライアント検証も含まれていますか？

あなたはベアラトークンを持っているので、RFC-6750が適用されます。 脅威軽減セクションでは、あなたの質問に答えます。

• まず、あなたのアクセストークンは、クライアントアプリと（トークンを取得するために）認証サーバ間のTLSのバージョンであれば、との間を開示することもできますクライアントアプリケーションとリソースサーバー（トークンを与える）にセキュリティ上の欠陥がある（抜粋：）。クライアントとリソースサーバーの間の通信だけでなく、クライアントと認証サーバー間の通信のやりとりが機密性TLSはこの仕様を実装して使用することが必須であるため、トークンの漏洩を防止するための好ましい方法です通信チャネルを介して受信する。）

• 第2に、アクセストークンを公開する別の方法は、です.TLSアクセラレータを使用する場合です。 RFC：の同じセクションで述べたように、ロードバランサを使用する展開を含むいくつかの展開では、リソースサーバーへのTLS接続は、リソースを提供する実際のサーバーの前に終了します。これにより、TLS接続が終了するフロントエンドサーバーとリソースを提供するバックエンドサーバーの間にトークンが保護されないままになる可能性があります。

開示されているアクセストークンを取得する他の方法があります。

解決策は、別のOAuthフローを実装するのではなく、RFCのセクション5.3で提案を適用することです。要約すると、メインrecommandationsは以下のとおりです。

• は常に、
• 検証TLS証明書チェーンをTLSを使用し、
• はTLS保護の使用に加えて、トークンの暗号化を使用します。例えば、でトークンを暗号化しますクッキーのトークンベアラ保存しない
• クライアントアプリケーションとリソースサーバ間の共有秘密、
• 問題短命ベアラトークン、
• スコープ付きベアラートークン（視聴制限を使用）。

これはRFCにはありませんが、私はこの推奨事項を追加します：相互認証を使用してください。これは、クライアントアプリケーションがリソースサーバーによって検証されなければならないX.509証明書を持っている必要があることを意味します。これは、クライアントアプリケーションがリソースサーバーによって認識されているため（選択フローによっては実行できないため）、選択した特定のOauth2フローで可能です。