私のウェブサイトでは、ランダム化された値を含む隠しフィールドを配置し、同時にその値をセッションにも保存しています。フォームが送信されると、送信された値がセッションの値と一致することを確認します。
CSRF保護にはこれで十分ですか? Web サイトをハッキングして、ユーザーに無意識のうちに私の Web サイトへの POST を強制する人は、私が生成した CSRF トークンが何であるかわからないため、攻撃は失敗します。そのトークンを取得する唯一の方法は、サーバーに対して GET 要求を実行し、Cookie を抽出して投稿することです。
それは可能ですか？言い換えれば、CSRF に対する保護の一部として Cookie を含める必要がありますか? ここで言及されているのを見たことがない: https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet#Disclosure_of_Token_in_URL
「Cookie の二重送信」の部分を除きます。
はい、CSRF保護には十分です。保護を最大限に高めるために、非表示のランダム化された値 (CSRF トークン) が、リクエストが行われるたびに変更されるようにしてください。
Cookie は使いやすく、ほとんどの Web フレームワークには Cookie を利用するための便利な方法が組み込まれているため、一般的に推奨されます。
一般的に、これは良いアプローチです。
確認したいセッション固定防止との相互作用があります。ユーザーがログインする (または、change-user、new-account、password-reset による暗黙的なログインなどの他の手段でセッションの特権レベルを変更する) 場合、古いセッションに保存されたアンチ CSRF トークンを破棄する必要があります。新しいものを生成します。
これは、攻撃者がアプリに対してセッション固定攻撃を仕掛けた場合に、それを使用してユーザーをセッションに入れ、ユーザーがログインするのを待ってから CSRF を送信することができないようにするためです。もちろん、とにかくセッションの固定化が起こらないようにする必要がありますが、これは有効な多層防御手段です。(特に、脆弱な近隣ドメインからの Cookie インジェクションなど、いくつかの潜在的なセッション修正ルートは、開発者として制御できない可能性があります。)
特権レベルの変更時に、セッション固定攻撃がアカウントへのフルアクセスを取得するのを防ぐために、セッション識別子を無効にして再発行する必要があるため、これは一般的に簡単です。その作業に追われている間に、CSRF トークンも変更してください。
(ただし、一部のガイドで推奨されているように、リクエストごとに CSRF トークンを再生成する必要はありません。これにより、アプリケーションがナビゲーションやマルチタブの使用に対して脆弱になります。)