CSRFトークンの検証方法

Question

私はHapiのプラグインCrumbを使ってCSRF攻撃を解決しようとしていますが、私は解決策の流れを得ていないようです。 私は単純に、各httpレスポンスにトークンをクッキーとして設定できます。クライアントがトークンを発行した場合、RESTがCSRFトークンを検証する方法は？ RESTバックエンドがこのランダムな文字列がこの要求に対して有効で、別のランダムな文字列が何であるかを理解する方法は？

Answer 1

クライアントでCSRFトークンを生成することはできません。これはサーバーからクライアントに最初に送信する必要があり、一部のJSフレームワークはCookieから自動的に抽出してサーバーに送信します。

基本的な考え方は、ユーザーがクッキーとともにトークンを送信することになっていることと、ポストデータにもあるということです。ここに簡単な例があります。攻撃者が特定のリクエストをサービスに送信するようユーザーを欺く場合、たとえば悪意のあるWebサイトにはこのリンクの画像src="gmail.com/deleteaccount=true"がある可能性があります。ユーザーがgmailにログインしている場合。 Gmailは、リクエストとともに送信されたCookieが有効であるため、リクエストを行ったユーザーであると考えます。だから、それが実際にユーザーであることを確認するために、gmailは要求データと共にトークンを送信する必要があります。gmail.com/deleteaccount=trueの代わりに、gmail.com/deleteaccount=true&token=987y23459827345sdfg.のトークンがCookieに格納されているものと一致する必要があります。したがって、リクエストがサーバーによって受信されると、Cookie内のトークンがリクエスト本体内のトークンと等しいかどうかがチェックされます。攻撃者はユーザーのCookieにアクセスできず、トークンを知らない。ここ は、単純化されたデータフローである：より詳細に

それは次のようになります。

• 1）ユーザーは、とクッキーを設定し、サーバー
• 2）サーバーにGETリクエストを送信します sessionidトークンでセッションデータを保存する
• 3）サーバーは、隠しフィールドにトークンを含むフォームでHTMLを返します。
• 4）ユーザーがセッションストレージに保存されたトークンを使用して隠しフィールド
• 5）サーバが 送信されたフォーム（非表示フィールドからトークンを比較）と共に、 フォームを送信します。一致する場合は、ユーザーがフォームを送信したことを意味します。ここで

別の火格子の答えです：Why is it common to put CSRF prevention tokens in cookies?