JWTトークンを使用するCookieの場合はhttp_only
SPAのCookieで送信されるJWTの使用方法を理解しようとしています。非Ajaxリクエストにもjwtを送信させたいので、Cookieに含める必要があり、すべてのサブドメインで「正常に動作する」はずです。サーバー側でトークンが生成および更新されているCookieがあります。私が理解しようとしているのは、クライアント側がどのように情報（is_logged_inとログインしたユーザーのユーザー名）にアクセスし、その情報をサーバー側のCookieライフサイクルと同期させるかです。リクエストがないため、ブラウザに表示されます。私の問題は、XSSを防ぐために、必要なユーザー情報がhttp_onlyのcookieにあることです。私はいくつかのオプションを考えましたが、妥当なセキュリティの妥協とは何かについて意見を求めています。
1）2つのCookieで同じjwtトークンを送信します。1つは実際のサーバー側の認証と認証に使用され、http_onlyと安全なフラグが付けられ、2つ目は同じですがhttp_onlyではないため、クライアントはそれをデコードして現在のユーザー情報を取得できます。と有効期限。
2）http_onlyではなくプレーンビューであるが、ログインしたユーザーのユーザー名しか持たない2番目のCookieでユーザー情報を送信します。
3）クライアントが自分でログイン情報を追跡するようにしてください。これは、これまでのところ問題があり、簡単に混乱するようですが、安全でないcookieが飛んでいません。
私は上記のオプションのいくつかのセキュリティ面を見逃している可能性があると考えているので、ここで質問します。ありがとう！
これは問題なく聞こえ、ユーザー名の値を非httpのみのCookieに複製することにより、XSS攻撃からセッションCookieを保護するための優れたソリューションのようです。
とにかく、すべての承認チェックはサーバー側で行う必要があります。したがって、クライアントがサーバーサイドで何かを実行したい場合、クライアントはリクエストを送信し、サーバーは非HTTPのみのCookieをまったく考慮せずに認証チェックを行います-HTTPのみで保護されたセッションCookieを使用するだけです。
非httpのみがUI目的でのみ使用されている場合、サーバーはセッションCookieを使用してすべてのリクエストを検査するため、セッションに害を及ぼすことはありません。
オプション1で何を説明しているかを理解するために、質問を数回読まなければなりませんでした-セッションCookieに予測可能なクリアテキストの値が含まれている場合（例では、認証されたユーザー名と認証されているという冗長な事実）、セキュリティ基本的に壊れています。セッションはランダムであるか、初期化値/ソルトが時間で変化するように暗号化する必要があります。
2番目のオプションでは、セッションCookieが安全であると想定した場合、2番目の安全でないCookieが侵害された結果はどうなりますか？それほど多くない。 Cookieが危険にさらされる可能性のある手段のほとんどは、ブラウザタイプの攻撃（xssを含む）の男に相当します。この時点で、攻撃者はセッションCookieを悪用して、被害者のブラウザからのリクエストを作成できます。 。