JWTをブラウザのどこに保存しますか？ CSRFから保護する方法は？

Question

Cookieベースの認証を知っています。 SSLおよびHttpOnlyフラグを適用して、Cookieベースの認証をMITMおよびXSSから保護できます。ただし、CSRFから保護するには、さらに特別な対策が必要になります。それらは少し複雑です。（参照）

最近、JSON Web Token（JWT）が認証のソリューションとして非常に熱いことを発見しました。 JWTのエンコード、デコード、検証に関することは知っています。ただし、JWTが使用されている場合、一部のWebサイト/チュートリアルでCSRF保護が不要であると言われる理由はわかりません。私は非常に多くを読み、以下の問題を要約しようとしています。誰かがJWTの全体像を提供し、JWTについて誤解した概念を明確にしたいのです。

JWTがCookieに保存されている場合、Cookieベースの認証と同じだと思いますが、Cookie /トークンを検証するためにサーバーにセッションが必要ない点が異なります。特別な対策が実装されていない場合、CSRFに関するリスクは依然として存在します。 JWTはCookieに保存されていませんか？
JWTがlocalStorage/sessionStorageに保存されている場合、Cookieがないため、CRSFから保護する必要はありません。問題は、JWTをサーバーに送信する方法です。 here は、jQueryを使用して、ajaxリクエストのHTTPヘッダーでJWTを送信することを提案しています。では、Ajaxリクエストのみが認証を実行できますか？
また、「Authorization header」と「Bearer」を使用してJWTを送信する blog のショーがもう1つ見つかりました。ブログが述べている方法がわかりません。誰かが「Authorization header」と「Bearer」について詳しく説明していただけますか？これにより、すべてのリクエストのHTTPヘッダーによってJWTが送信されますか？はいの場合、CSRFはどうですか？

MvdD · Accepted Answer

JWTトークンは、 OAuth 2. や OpenID Connect などの新しい承認および認証プロトコルでデフォルトのトークン形式として使用されるため、人気があります。

トークンがCookieに保存されると、ブラウザは同じドメインに各リクエストとともにトークンを自動的に送信しますが、これはまだCSRF攻撃に対して脆弱です。

ベアラー認証は、HTTPで定義されている認証スキームの1つです。基本的に、YOUは、リクエストのAuthorization HTTPヘッダーに（JWT）トークンを貼り付けることを意味します。ブラウザはNOTを自動的に実行するため、Webサイトの保護には適していません。ブラウザはリクエストにヘッダーを自動的に追加しないため、CSRF攻撃に対して脆弱ではありません。CSRF攻撃は、認証情報が元のドメインに自動的に送信されることに依存します。

ベアラスキームは、AJAX呼び出しまたはモバイルクライアントから消費されるWeb API（RESTサービス）を保護するためによく使用されます。

Iman Sedighi · Answer

クライアントコンピューターにJWTを保存する必要があります。 LocalStorage/SessionStorageに保存すると、XSS攻撃によって簡単に取得できます。 Cookieに保存すると、ハッカーはCSRF攻撃で（読み取らずに）それを使用してユーザーになりすまし、APIに連絡し、ユーザーに代わってアクションを実行したり情報を取得したりするリクエストを送信できます。

ただし、簡単に盗まれないようにJWTをCookieで保護するにはいくつかの方法があります（ただし、それらを盗むための高度な技術がいくつかあります）。ただし、LocalStorage/SessionStorageに依存する場合は、単純なXSS攻撃でアクセスできます。

したがって、CSRF問題を解決するために、アプリケーションでDouble Submit Cookiesを使用します。

二重送信Cookieメソッド

JWTをHttpOnly Cookieに保存し、セキュアモードで使用してHTTPS経由で転送します。
CSRF攻撃のほとんどは、リクエストに元のホストとは異なるOriginまたはリファラーヘッダーがあります。そのため、ヘッダーにそれらのいずれかが含まれているかどうかを確認してください。それらはドメインから来ているかどうかです。それらを拒否しない場合。オリジンとリファラーの両方がリクエストで利用できない場合、心配はありません。次のステップで説明するX-XSRF-TOKENヘッダー検証結果の結果に依存できます。
ブラウザーは要求のドメインのCookieを自動的に提供しますが、1つの有用な制限があります。Webサイトで実行されているJavaScriptコードは、他のWebサイトのCookieを読み取ることができません。これを活用して、CSRFソリューションを作成できます。 CSRF攻撃を防止するには、XSRF-TOKENというJavascriptで読み取り可能な追加のCookieを作成する必要があります。このCookieは、ユーザーがログインしたときに作成する必要があり、ランダムで推測できない文字列を含める必要があります。また、この番号をプライベートクレームとしてJWT自体に保存します。 JavaScriptアプリケーションが要求を行うたびに、このトークンを読み取り、カスタムHTTPヘッダーで送信する必要があります。これらの操作（Cookieの読み取り、ヘッダーの設定）はJavaScriptアプリケーションの同じドメインでのみ実行できるため、JavaScriptアプリケーションを使用している実際のユーザーによって実行されていることがわかります。

Angular JSはあなたの人生を楽にします

幸いなことに、プラットフォームでAngular JSを使用しており、AngularがCSRFトークンアプローチをパッケージ化しているため、実装が簡単になっています。 Angularアプリケーションがサーバーに対して行うすべてのリクエストに対して、Angular $httpサービスはこれらのことを自動的に行います。

現在のドメインでXSRF-TOKENという名前のCookieを探します。
そのCookieが見つかった場合、値を読み取り、X-XSRF-TOKENヘッダーとして要求に追加します。

したがって、クライアント側の実装は自動的に処理されます！サーバー側の現在のドメインにXSRF-TOKENという名前のCookieを設定するだけで、APIがクライアントから呼び出しを受け取ったときに、X-XSRF-TOKENヘッダーを確認し、JWTのXSRF-TOKENと比較する必要があります。それらが一致する場合、ユーザーは本物です。それ以外の場合、それは偽造されたリクエストであり、無視できます。このメソッドは、「Double Submit Cookie」メソッドに触発されています。

あぶない

実際には、あなたはまだXSSの影響を受けやすく、攻撃者が後で使用するためにJWTトークンを盗むことはできませんが、XSSを使用してユーザーの代わりにリクエストを行うことができます。

JWTをlocalStorageに保存するか、XSRFトークンをHttpOnly Cookieに保存するかにかかわらず、両方ともXSSによって簡単に取得できます。 HttpOnly CookieのJWTでさえ、 XSTメソッド。のような高度なXSS攻撃によって取得できます。

そのため、Double Submit Cookiesメソッドに加えて、コンテンツのエスケープを含むXSSに対するベストプラクティスに従う必要があります。これは、ブラウザが望まないことをする原因となる実行可能コードを削除することを意味します。通常、これは、JavaScriptが評価される原因となる// <![CDATA[タグとHTML属性を削除することを意味します。

詳細はこちら：