web-dev-qa-db-ja.com

認証トークンをクライアント側に保存するのに最適な場所

ユーザーが認証されると、認証トークンを受け取ります。この認証トークンを使用して、一部のasp.net WebAPI呼び出しを承認する必要があります。これを行うには、その呼び出しの先頭にトークンを追加する必要があるため、ユーザーのブラウザーからアクセスできるトークンが必要です。トークンをCookieに保存するのは最も安全な方法ではないと思います。そのため、そのトークンを保存し、JavaScriptでアクセスしてAPI呼び出しを行う最も安全な方法は何ですか？

web-applicationoauth.net
65
jfamvg

ブラウザに認証情報を保存するには、2つの方法があります。

  1. クッキー
  2. HTML5 Webストレージ

いずれの場合も、ブラウザーが正しく実装されており、WebサイトAがWebサイトBの認証情報にアクセスできないことを信頼する必要があります。その意味で、両方のストレージメカニズムは同等に安全です。ただし、使用方法に関して問題が発生する可能性があります。

Cookieを使用する場合：

  • ブラウザは、APIへのすべてのリクエストで認証情報を自動的に送信します。これは、発生していることがわかっている限り便利です。
  • CSRFは重要なことであり、それに対処する必要があります。

HTML5 Webストレージを使用する場合：

  • いつ、どの認証情報が送信されるかを正確に管理するJavaScriptを記述する必要があります。

人々が気にする大きな違いは、CookieではCSRFを心配する必要があるということです。 CSRFを適切に処理するには、通常追加「同期トークン」が必要です。

オールインワンのWebフレームワーク（Grails、Rails、おそらくasp.netなど）は通常、CSRF保護を有効にする簡単な方法を提供し、UIにシンクロナイザートークンを自動的に追加します。ただし、クライアント側のみのWebフレームワーク（AngularJSやBackboneJSなど）を使用してUIを作成している場合は、シンクロナイザトークンを管理するためのJavascriptを作成する必要があります。したがって、その場合は、HTML5 Webストレージアプローチを使用して、1つのトークンのみを心配することもできます。

他のいくつかの違いについて説明します ここ 。

editgoogle.searchがasp.netの this を明らかにします-彼らはシンクロナイザトークンを「リクエスト検証トークン」と呼びます。

58
Chris Clark

アクセストークンを保護する最善の方法は、クライアント側にトークンを保存しないことです。

それはどのように機能しますか？アクセストークンを生成する時点で、他の暗号的に安全な [〜＃〜] prng [〜＃〜] （サーバーのアクセストークンにマッピングする）を生成し、これをユーザーのセッションIDをクライアントに返します。

これにより、現在返されているのはセッションに関連付けられたトークンであり、トークンを認証するために両方が必要になるため、攻撃領域が減少します。セッションが期限切れになると、当然、トークンも期限切れになり、ユーザーは再認証を強制されるため、新しいアクセストークンが生成されます。

それでも100％安全ではありませんが、ユーザーセッション内でこのようなことが発生する可能性を検討する必要があります。これに基づいて、セッション/トークンの有効期限を調整して使いやすくすることができますが、使いやすさにも注意する必要があります。5分後にセッションを期限切れにしたくないので、常にログインし直すのは面倒です（または、可能であれば、アプリケーションのタイプによって異なります）。

9
James

ARMORは、特にこの要件を満たすように設計されています。偽造防止トークンは、UIの適切な場所に保存できます。このライブラリには、UIからトークンを抽出して自動的にAJAXヘッダーに含めるカスタムJavaScriptコンポーネントが搭載されています。

ここにチュートリアルがあります 件名、および ここにGitHubリポジトリがあります 。

1
Paul Mooney

すべての要求でサーバーにトークンを送信する必要があります。したがって、Cookieやhtml 5ストレージに保存してもかまいません。どちらも安全なストレージであり、クライアントマシンにアクセスできるeveyoneはとにかくトークンにもアクセスできます。

ただし、CSRF攻撃を防ぐために、サーバーのCookieで送信されたトークンを使用しないことをお勧めします。必要なときはいつでも、すべてのリクエストに手動でトークンを含めることをお勧めします。

Cookieを使用すると、要求ヘッダーも大きくなりますが、これは適切ではありません。

0
Mohammad Nikravan

次の3つのフラグを使用して、トークンをCookieに保存します。1.安全：https経由で送信2. HttpOnly：クライアント側のJSが読み取れません（XSS保護）3. SameSite（LaxまたはStrict）：CSRF保護

このようにして、XSSおよびCSRFの影響を受けなくなります。 SameSiteは比較的新しく、最近4つの主要なブラウザー（Chrome、FF、Safari、Edge）でのみサポートされているため、注意する必要があるのは以下を参照してください。 https://caniuse.com/#feat= same-site-cookie-attribute

Cookieの強化に関する詳細については、 https://odino.org/security-hardening-http-cookies/ を参照してください

0
fox

アレックスのブログは有益でなければなりません。

誰かがOAuthを実装するたびにサーバーが停止します。1つのページはWebアプリです。大量虐殺を止めてください！サーバー側のプロキシを使用してください！今すぐ行動してください！

https://github.com/alexbilbie/alexbilbie.github.com/blob/master/_posts/2014-11-11-oauth-and-javascript.md

0
zono