CSRF（CWE-352）は非常に有名な脆弱性の一つの名称です。対策と言えばCSRFトークンという事で、フレームワークやライブラリに任せて、流れるように対応を進めているパターンが多いのではないでしょうか。
そんなある意味枯れてきている脆弱性について、最近とあるブログを見て改めて考えさせられた部分があるため、少し記載してみたいと思います。

CSRFとは

Cross-Site Request Forgery（クロスサイト・リクエスト・フォージェリ）は『しーさーふ』とも呼ばれる昔から存在している有名な脆弱性です。
脆弱性のあるサイトの利用者が、罠サイトやメールのリンクを経由して、意図しない処理を実行させられてしまう攻撃手法となります。

詳細な説明や発生しうる脅威、注意が必要なサイトなどは上記画像の引用元であるIPAのサイトや他にも良い紹介サイトなど沢山あるので、そちらを参考にしてください（今回はそちらには触れません）

CSRFへの対策

CSRFの名前の表す通り、この脆弱性はクロスサイト（複数サイト経由）におけるリクエストの偽装にあります。特に、登録・更新・削除処理という、いわゆる状態を変更させるような処理（ここでは副作用と呼んでおきます）が対象となります。
その対策として、サーバ側、ブラウザ側などで色々な対策が考えられ活用されてきました。

CSRFトークン

CSRFトークンは副作用が発生するリンクの前後のページでOTP（ランダム文字列）をトークンとして、それが正しい遷移であることをチェックする意味を持ちます。現状では、一番採用されている対策ではないでしょうか。

SameSite Cookie属性

SameSite Cookie属性はクロスサイトにおけるCookie送信ルールを定義出来る仕組みで、2020年頃から導入が進んできた、いわゆる3rd Party Cookieに対しての対策となります。
この属性を正しく設定することで、クロスサイトにCookieを飛ばさない＝Cookieを利用した認証を継続出来ない→意図しない処理の実行に至らないという構図が出来上がります。
ただし、それは認証状態が継続しないという効果であって、正しい遷移であることのチェックではありません。

認証におけるJWT（ジョット）の利用

JWT保存先の議論はさておき、Cookieのように自動で送信される認証トークン以外を利用する事で、認証継続に対しての対策とすることができます。
ただし、これもSameSite Cookieの件と同様に認証状態を継続出来ないという効果であって、正しい遷移のチェックではありません。

Originヘッダの利用

最近（といっても7年くらい前かららしい）のブラウザは、formリクエスト時に自身のドメインなど情報を送信してくれます。これは、ブラウザで変更不可能として定義されているため、比較的安全にクロスサイトリクエストの判断に利用が可能です。
ちなみに、Refererヘッダとイメージ似ている部分もありますが、RefererヘッダはProxyで削除されてしまったり、改変されてしまったりすることもあり、セキュリティ的には意味を成さないと考えるのが一般的です。（保険的に利用する事はありえます）

対策から見えてくるもの

いくつかの対策を記載しましたが、CSRFトークンとOriginヘッダの対策が直接的なCSRF対策と言えるのではないでしょうか。
最新のブラウザだけを対象とするなら、Originヘッダのチェックだけでも良い気もしますが、同じドメインのサイトに攻撃スクリプトが埋め込まれたらそのチェックは無効化されてしまいます（それは別途XSSなどの脆弱性があるからであって、根本原因は別だとは思いますが）
色々な脆弱性対策にも言えることだと思いますが、多層防御の観点から複数の対策を併用するのが良いのではないかと個人的には思っています。

補足

次のメソッド（GET、HEAD、OPTIONS）では、副作用を発生させないなどの、一般的な観点で作成されたウェブサイトを前提とした内容になります。
Preflight request（プリフライトリクエスト）の話や、CORSの話などは今回は割愛しています。（この辺の仕様って複雑ですよね、、、）

さいごに

今回お伝えしたかった事は、実はCSRFの具体的な対策の内容ではありません。
一般的な対策だと思われているものでも、実は最新の情報に更新されていたり、意味を取り違えて（結果的にOKでも）利用している事がよくあります。そのため、改めて（誰かが書いてくれたブログからでも）トレンドを追いかける事、さらにそれを誰かに伝える事が改めて大事だと気づいた事にあります。（なので今回ブログに書きました。自分の理解もより深まります。）

～以下宣伝です～

当社ではWebサイトの脆弱性に対して、Webサイトの脆弱性診断以外に、多層防御の観点からWAF（Web Application Firewall）のご提案も行っています。
今回のCSRFについてもWAFを導入しておく事も一つの対策になりえます。
興味がありましたら、ぜひこちらからお問い合わせいただければ幸いです。