ステートレス（=セッションレス）認証を使用する場合、CSRFトークンは必要ですか？

アプリケーションがステートレス認証（HMACなどを使用）に依存している場合、CSRF保護を使用する必要がありますか？

例：

• シングルページアプリがあります（そうでない場合、各リンクにトークンを追加する必要があります：）<a href="...?token=xyz">...</a>。

• ユーザーはを使用して自分自身を認証しPOST /authます。認証が成功すると、サーバーはトークンを返します。

• トークンは、JavaScriptを介して、単一ページアプリ内の変数に格納されます。

• このトークンは、などの制限されたURLへのアクセスに使用されます/admin。

• トークンは常にHTTPヘッダー内で送信されます。

• HttpセッションもCookieもありません。

私が理解している限り、ブラウザはトークンを保存しないため、クロスサイト攻撃を使用する可能性はありません（？！）。したがって、サーバーにトークンを自動的に送信することはできません（Cookies /セッション）。

何か不足していますか？

認証にCookieを使用しない CSRF +に関する情報が見つかりました。

1. https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/「Cookieに
   依存していないため、クロスサイトリクエストから保護する必要はありません」

2. http://angular-tips.com/blog/2014/05/json-web-tokens-introduction/「Cookieを使用する
   場合は、CSRFを実行してクロスサイトリクエストを回避する必要があります。これは、 JWTを使用するときに忘れないでください。」
   （JWT = Json Web Token、ステートレスアプリのトークンベースの認証）

3. http://www.jamesward.com/2013/05/13/securing-single-page-apps-and-rest-services
   "CSRFの脆弱性を危険にさらすことなく認証を行う最も簡単な方法は、Cookieを使用してユーザーを識別するのを単に避けることです」

4. http://sitr.us/2011/08/26/cookies-are-bad-for-you.html「CSRF
   の最大の問題は、Cookieがこのタイプの攻撃に対する防御をまったく提供しないことです。Cookie認証を使用している場合また、CSRFから保護するために追加の対策を講じる必要があります。取れる最も基本的な予防策は、アプリケーションがGETリクエストに応答して副作用を実行しないことを確認することです。」

認証にCookieを使用しない場合は、CSRF保護が必要ないことを示すページは他にもたくさんあります。もちろん、他のものすべてにCookieを使用することはできますが、そのようなものを保存することは避けてくださいsession_id。

ユーザーを覚えておく必要がある場合は、2つのオプションがあります。

1. localStorage：ブラウザー内のKey-Valueストア。保存されたデータは、ユーザーがブラウザウィンドウを閉じた後でも利用できます。すべてのサイトが独自のストレージを取得するため、他のウェブサイトからデータにアクセスすることはできません。

2. sessionStorage：ブラウザ内のデータストアにもあります。違いは、ユーザーがブラウザウィンドウを閉じるとデータが削除されることです。ただし、Webアプリケーションが複数のページで構成されている場合は、それでも役立ちます。したがって、次のことができます。

   • ユーザーがログインしてから、トークンを保存します sessionStorage
   • ユーザーがリンクをクリックすると、新しいページがロードされます（= 実際のリンク、JavaScriptコンテンツの置き換えなし）
   • 引き続きトークンにアクセスできます sessionStorage
   • ログアウトするには、トークンを手動で削除するかsessionStorage、ユーザーがブラウザウィンドウを閉じるのを待つことができます。これにより、保存されているすべてのデータが消去されます。

（どちらもここにあります：http : //www.w3schools.com/html/html5_webstorage.asp）

トークン認証に公式の基準はありますか？

JWT（Json Web Token）：まだ草案だと思いますが、すでに多くの人が使用していて、コンセプトはシンプルで安全に見えます。（IETF：http : //tools.ietf.org/html/draft-ietf-oauth-json-web-token-25）
利用可能な多くのフレームワーク用のライブラリもあります。ただググって！

TL; DR

JWTをCookieなしで使用すると、CSRFトークンの必要性がなくなります-しかし！JWTをsession / localStorageに保存することで、サイトにXSSの脆弱性がある場合（かなり一般的）にJWTとユーザーのIDを公開します。csrfTokenJWTにキーを追加しsecure、http-only属性が設定されたCookieにJWTを保存することをお勧めします。

詳細についてはこの記事をよく読んでください https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage

xsrfToken JWTクレームを含めることで、このCSRF保護をステートレスにすることができます。

{ "iss": "http://galaxies.com", "exp": 1300819380, "scopes": ["explorer", "solar-harvester", "seller"], "sub": "tom@andromeda.com", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }

したがって、csrfTokenをlocalStorage / sessionStorageとJWT自体（httpのみで安全なcookieに格納されている）に格納する必要があります。次に、csrf保護のために、JWTのcsrfトークンが送信されたcsrf-tokenヘッダーと一致することを確認します。