web-dev-qa-db-ja.com

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

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

例:

  • 単一ページのアプリがあります(それ以外の場合は、各リンクにトークンを追加する必要があります:<a href="...?token=xyz">...</a>

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

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

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

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

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

私が理解している限り、ブラウザはトークンを保存しないため、クロスサイト攻撃を使用する可能性はありません(?!)セッション)。

何か不足していますか?

111
Benjamin M

認証にnoCookieを使用する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を使用することはできますが、avoidsession_idのようなものを保存してください。


ユーザーを記憶する必要がある場合、2つのオプションがあります。

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

  2. sessionStorage:ブラウザデータストアにもあります。違いは、ユーザーがブラウザウィンドウを閉じるとデータが削除されることです。しかし、webappが複数のページで構成されている場合、それはまだ便利です。したがって、次のことができます。

    • ユーザーがログインしたら、トークンをsessionStorageに保存します
    • ユーザーがリンクをクリックすると、新しいページが読み込まれます(= arealリンク、javascript content-replaceはありません)
    • 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
多くのフレームワーク用のライブラリも用意されています。ただグーグル!

148
Benjamin M

TL; DR

JWTは、Cookieなしで使用すると、CSRFトークンの必要性を無効にします-しかし! JWTをsession/localStorageに保存することにより、サイトにXSS脆弱性がある場合(かなり一般的)、JWTとユーザーのIDを公開します。 csrfTokenキーをJWTに追加し、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": "[email protected]", "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e" }

そのため、csrfTokenをlocalStorage/sessionStorageとJWT自体(http専用のセキュアCookieに格納されている)に格納する必要があります。次に、csrf保護のために、JWTのcsrfトークンが送信されたcsrf-tokenヘッダーと一致することを確認します。

53
Scott Jungwirth