.netコアを使用してクッキーにJWTを保存する方法

Question

コントローラのユーザー権限を確認するために使用されるクレームには多くの問題があります。

のApp構造

私たちのバックエンドは、フロントエンドが反応し、今ため我々はGoogleの有効な電子メールを使用してGoogleのAPIを使用してログインをのみを許可し、.NETのコアです。 JWTを生成してブラウザのlocalStorageに格納し、リクエストごとに送信します。また、ロールはありません。ログに記録されている場合は管理者です。

アプリの「スケルトン」を実行した開発者はいなくなりました。これはセキュリティ上の懸案事項で初めてのことです。

新しい要件

私たちは、役割と権限を実装するために今必要な、MSが1本のためにクレームを使用する予定らしいです。私はこれを行い、それらの主張をjwtに追加してから、設定に関するポリシーを追加し、実際に働いた。特定の要求がある場合は、特定のコントローラーまたはメソッドにアクセスできます。そうでない場合、サーバーは403エラーを返します。

しかし、実際の管理者の役割でログインし、devtoolsを使用してlocalStorageの値をコピーした後、ほとんどの権限のないユーザーでログオフして戻しました。私はローカルのストレージエントリを（再び、devtoolsを使用して）貼り付けたときにすぐにすべてのクレームを取得し、管理者ができるすべてのコントローラとメソッドにアクセスできました。

その後のHttpOnlyを使用する必要があります行くための適切な方法と思われる、セキュアなクッキー、「SameOriginが」真（これはシングルサインオンをどのように影響するかわからない）に設定し、おそらくで、私はを行う方法をを理解していませんそれ。私はブログ記事を見て、アプリをダウンロードしても（実行することはできませんでしたが、私のアプリケーションにコードをコピーしました）、私は失敗し続けます。また、コントローラのポリシーをチェックするときにクッキーを使用するために何かをする必要があるかどうかもわかりません。

誰も私にこの手を差し伸べることはできますか？

Answer 1

攻撃者がユーザーのブラウザに入ることができれば、access_tokenを盗むよりもはるかに多くのダメージを与える可能性があります。 Auth0.comのthis threadをチェックしてください。基本的に：

他の人のブラウザからJWTを盗む立場にいるとします。 あなたがそれを行うことができる方法に応じて2つのシナリオが考えられます。

1. あなたはどちらかだけのトークンを盗むより多くのダメージを引き起こす状況にあります。
2. あなたは実際のパスワードを盗まれたJWTを格納する代わりに、それがずっと悪いと想像してください。

主な違いは、JWTsがXSSに対してより脆弱であるが、クッキーはXSRFに対してより脆弱であるということです。また

、1つのより有用引用あなたはJWTの上にクッキーを選択したい場合：

クッキーのためにプロがある：XSSに対する

• 安全あなたが使用して喜んでいると仮定するとHTTPのみクッキー

短所は以下のとおりです。

• JSコードでJWTにアクセスすることはできません。
• ヘッダーの手法はこれに脆弱ではなく、Cookieが存在するため、CSRFに対する要求を保護する必要があります。
• APIコードでは、Cookie（ブラウザ）またはヘッダーからのJWTを処理する必要があります（APIを呼び出す他のサーバーは ヘッダーを使用する必要があります）。
• APIがサイトと同じドメインにある場合、Cookieが動作します。 APIが別のドメインにある場合には使用できません。

に、それはあなたがhereを説明したミドルウェアを変更する必要があります代わりに、HTTPヘッダーのクッキーからJWTを検証し約3分のポイントになります。

個人的には、ReactJSを使用すると、SPAアプリケーション用にもっとsuitableなので、私はJWTモデルを保持します。 「ローカルストレージエントリを貼り付けると（devtoolsを使用して）すぐにすべてのクレームが得られます」は基本的に攻撃者がコンピュータの前に座っていることを意味します。その場合、JWTトークンを盗みます懸念はほとんどありません。

JWTトークンに有効期限を設定する必要があることを覚えておいてください。