ローカルホストの開発と展開のためのMVC IDクッキーのセキュリティベストプラクティス

自分のコンピュータに複数のASP MVCプロジェクトがあり、それぞれがIDCフレームワークと[Authorize]属性を持つさまざまなコントローラを使用しています。ローカルホストの開発と展開のためのMVC IDクッキーのセキュリティベストプラクティス

私はあるプロジェクトでログインし、次にlocalhostで別のものをデバッグすると、他のプロジェクトのセキュリティをバイパスできます。

ローカルホスト用のクッキーが1つしかないので、これは理解していますが、デバッグ目的でこの問題を回避する方法は簡単ですか？公共のインターネットに展開する際にセキュリティ上の問題はありますか？

出典

2016-09-25 Wil

認証を設定するときは、各プロジェクトで異なるCookieName値が指定されていることを確認してください。 –

@ TiesonT.-私はクッキーに問題はありません。名前を変更できないデフォルトの認証クッキーに問題があります。また、私が言ったように、私はそのプロジェクトに存在しないユーザーと別のアプリケーションにログインできる場合、私はインターネットに導入するためのベストプラクティスについて知りたいと思っています... – Wil

なぜあなたは変更できません認証クッキーの名前？これは常にFormsAuthenticationの一部であり、OWINも変わりません。 AuthorizeAttribute（ロールやクレームなし）を適用するだけであれば、認証Cookieが存在するかどうかをチェックし、現在のアプリケーションからのものではありません –

@TiesonTによれば、各アプリケーションの認証Cookieの名前を変更する必要があるため、あなたはStartup.Auth.csでそれを行うことができます。

app.UseCookieAuthentication(new CookieAuthenticationOptions 
{ 
    // other properties 
    CookieName = "MyCookieName", 
});

代わりにあなたがIISであなたのdevのマシン上でアプリケーションを設定し、hostsファイルを介してそれらにそれぞれ独自のドメイン名を与えることができます。私。 MyApplication.devMyOtherApplication.dev

出典

2016-09-26 11:46:47 trailmax

ローカルホストの開発と展開のためのMVC IDクッキーのセキュリティベストプラクティス

答えて

関連する問題