CSRF：Cookieを使用できますか？
CSRFトークンをCookieに入れても大丈夫ですか？ （そして、すべての形式で、隠された入力として、もちろん、それらが一致するかどうかを確認できます）理由はわかりませんが、そうすることはトークンの目的全体を打ち負かすと誰かが言うのを聞きました。それは私には安全なようです。
そして、それが安全である場合、URLにトークンを置くよりも安全性が低いのでしょうか？
他に方法はありますか？
このテーマについてもっと読むことができますか？
[〜＃〜] update [〜＃〜]：これまでのところ、攻撃者がすべきではないフォームのトークンと一致する必要がある場合、Cookieメソッドが安全でない理由を誰も教えてくれません。 XSSのような別のハックを使用しない限り、取得することはできません。これは別の問題であり、CookieとURLトークンの使用に違いはありません。
PDATE 2：わかりました、いくつかの有名なフレームワークがこのメソッドを使用しているようですので、問題ないはずです。ありがとう
Cookieの使用は機能し、一般的な方法です（例： DjangoはCookieを使用します ）。攻撃者は、同一生成元ポリシーのためにCookieの値を読み取ったり変更したりできないため、正しいGET/POSTパラメーターを推測できません。
暗号化されたトークンパターン を確認してください。これにより、サーバーにトークンを保存しなくてもステートレスCSRF保護が可能になります。
"多くのサイトがGETリクエストを使用してコマンドを実行するため、CSRFは機能します。"したがって、多くのサイトはGETメソッドを期待どおりに使用しません。 rfc2616を参照 。
"CSRFパラメータはすでにCookieにあり、セッションと一緒に送信されます。"では、どのようにしたらよいでしょうか。
非表示の入力フィールドにトークンを設定するときのDOMとして、Cookieはトークンストレージのみを使用して使用されます。 JavaScriptの一部は、このCookieからトークン値を取得し、それをURL、リクエスト本文、またはリクエストヘッダーのパラメーターとして設定する必要があります。セッションに保存されている値でサーバー上でチェックされます。これが、CSRFトークンを処理するDjangoの方法です。
クロスドメインブラウザ保護のため、Javascriptは別のドメインからCookieにアクセスできません。そのため、悪意のあるユーザーが偽造されたリクエストに沿って正しいトークンを送信するように強制する方法がわかりません。 XSSの場合はそうですが、XSSは一般的なCSRF対策を打ち負かします。
これは重要な質問であり、扱いが簡単ではないと思うので、この説明をすることを好みます。
GETリクエスト必須リソースの取得やデータの表示に使用し、必須状態の変更（削除、プロパティのインクリメント、または変更）に使用します。
CSRF検証必須サーバー側で実行する必要があります。これは明らかなようですが、念のために言っておきます。 この推奨事項を守れば、このメソッドを攻撃のベクトルにすることはできません。
CSRFトークンをCookieに入れることにした場合は、そのCookieをHttpOnlyとしてマークすることを忘れないでください。サイトにクロスサイトスクリプティングの脆弱性がある場合、ハッカーはCSRFトークンを読み取ることができません。最新のブラウザコンソールでコマンドconsole.log(document.cookie)を使用して、JavaScriptで読み取ることができるCookieを確認できます。セッションCookieまたはその他の機密性の高いCookieがある場合は、これらもHttpOnlyとしてマークする必要があります。
参考文献：