クッキーベースの認証については知っています。SSL と HttpOnly フラグを適用すれば、クッキーベースの認証を MITM や XSS から保護できます。ただし、CSRF から保護するには、さらに特別な対策を適用する必要があります。少し複雑です。(参照）
最近、JSON Web Token (JWT) が認証ソリューションとして非常に人気があることを知りました。JWT のエンコード、デコード、検証については知っています。しかし、一部の Web サイトやチュートリアルでは、JWT を使用する場合は CSRF 保護は不要であると説明されている理由がわかりません。私はかなり多くの情報を読み、以下に問題をまとめようとしました。JWT の全体像を示し、私が誤解していた JWT の概念を明確にしてくれる人がほしいだけです。
JWT が Cookie に保存されている場合、サーバーが Cookie/トークンを検証するためのセッションを持つ必要がないことを除いて、Cookie ベースの認証と同じだと思います。特別な対策を実装しないと、CSRF のリスクが残ります。JWT は Cookie に保存されないのですか?
JWTがlocalStorage/sessionStorageに保存されている場合、クッキーは含まれていないため、CSRFに対する保護は必要ありません。問題は、JWTをサーバーに送信する方法です。ここjQuery を使用して、ajax リクエストの HTTP ヘッダーで JWT を送信することが推奨されています。つまり、ajax リクエストのみが認証を行うことができるということですか?
また、もう一つ見つけたブログこれは、JWT を送信するために「Authorization ヘッダー」と「Bearer」を使用することを示しています。ブログで説明されている方法が理解できません。誰か「Authorization ヘッダー」と「Bearer」について詳しく説明してもらえますか? これにより、すべてのリクエストの HTTP ヘッダーによって JWT が送信されるようになりますか? そうである場合、CSRF はどうなりますか?
ベストアンサー1
JWT はクライアント コンピューターに保存する必要があります。LocalStorage/SessionStorage に保存すると、XSS 攻撃によって簡単に取得される可能性があります。Cookie に保存すると、ハッカーがそれを (読み取ることなく) CSRF 攻撃で使用し、ユーザーになりすまして API に接続し、ユーザーに代わってアクションを実行したり情報を取得したりするためのリクエストを送信できます。
しかし、クッキー内の JWT が簡単に盗まれないように保護する方法はいくつかあります (ただし、それらを盗むための高度なテクニックはまだいくつかあります)。ただし、LocalStorage/SessionStorage に依存したい場合は、単純な XSS 攻撃によってアクセスされる可能性があります。
したがって、CSRF 問題を解決するために、アプリケーションで Double Submit Cookies を使用します。
ダブルサブミットCookieメソッド
JWT を HttpOnly クッキーに保存し、セキュア モードで使用して HTTPS 経由で転送します。
CSRF 攻撃のほとんどは、リクエストに元のホストとは異なる origin または referrer ヘッダーを持っています。したがって、ヘッダーにそれらのいずれかがあるかどうか、それらが自分のドメインから来ているかどうかを確認してください。ない場合は拒否します。リクエストに origin と referrer の両方がない場合でも心配はいりません。次のステップで説明する 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をHttpOnlyクッキーに保存するかlocalStorage、XSRFトークンをHttpOnlyクッキー以外に保存するかにかかわらず、どちらもXSSによって簡単に取得できます。HttpOnlyクッキー内のJWTでさえ、次のような高度なXSS攻撃によって取得される可能性があります。XST法。
したがって、Double Submit Cookies 方式に加えて、コンテンツのエスケープを含む XSS に対するベスト プラクティスに常に従う必要があります。つまり、ブラウザーに望ましくない動作を実行させる実行可能コードをすべて削除するということです。通常、これは// <![CDATA[JavaScript の評価を引き起こすタグと HTML 属性を削除することを意味します。
詳細はこちらをご覧ください: