セキュリティ：SSLを使用したASp.NET ID HTTPOnly Cookie

Question

これは、ユーザーオブジェクトがセッションに保存されているため、新しいIDフレームワークを学習しているため、一般的な質問です。

私は、「クレーム」をクッキーの一部として送信することについて多くの話をしています。そのようにして、ユーザー情報を再検索する必要はありません。名前、電子メール、または権限などの意味は、保存されているクッキー内のクレーム領域の一部です。

私がこれについて学んだことはすべて、SSL上のhttpOnlyはハッキングの点で非常に安全だと言います。私は何かを送信することを躊躇していますが、ユーザを識別するためにユーザIDを確認し、少なくともユーザがハッキングされているかどうかを確認するためにデータベース内の残りの部分を検索します。私は慎重に過ごしていますか？

また、クッキーを設定している人が7日間または1日以内に期限切れになるのを見る人もいます...それに関しては、クレームエリアで権限/役割を送信しています。サーバー上で変更された場合はどうなりますか。基本的には、新しい権限が発生するためには、ユーザーがログインしてログアウトする必要があるようです。ソフトウエアのUI標準で期待されていることが不思議でしたか？自分の考えを事前に

感謝:)

アンジェラ

Answer 1

自分の無知を許したが、私はクレームがクッキーに送信されるソフトウェアの一部に遭遇していませんでした。通常、Cookieの問題は、ブラウザに常に送信するように記述されているため、XSS（クロスサイトスクリプティング）攻撃の可能性があります。

アイデンティティプロバイダ（ログインページ）とサービスプロバイダ（アプリケーションコード）が必ずしも同じアプリではなく、常に直接接続されているわけではない。つまり、dbで検索できるユーザーのデータはIdPのみに存在し、SPはIdPが提供したものを処理する必要があります。

これは、情報の各ビットが「請求」で送信される理由です。これは、IdPがユーザー名がjohn.smithであると主張しているが、SPにはこれをチェックする手段がないことを意味する。

IdPとSPは、IDPがトークン（SAMLエンベロープやJWTなど）とSPに署名できるように、通常は事前共有署名鍵の形式で、ある形式の信頼を確立する必要がありますトークンが改ざんされていないことを確認できるように署名を検証する。

通常、このトークンはクッキーとして使用されません。その代わりに、Bearerスキームを使用して、Authorizationヘッダーに追加されます。

また、セッションの使用に慣れていると言えば、セッショントラッカーも（ASP.NETの）クッキーであることを理解する必要があります。サーバーには、アプリケーションプールのメモリキャッシュに格納されているユーザーに関する情報があり、ブラウザは「ここにいる」というCookieを送信し続けます。だからセキュリティが賢明なのは、単純にクッキーを使うこととクッキーとセッションを使うこととの間に匹敵するレベルです。もちろん、Cookieが情報を漏洩する可能性があると主張することもできますが、アプリは常にこのトークンを無効にしてデータをトークン化したり、Cookie全体を暗号化したりできます。