CSRF の防御は、別サイトのページが作れない信号を渡すこと

SameSite などで制限しない限り、トップレベルのフォーム送信では、Cookie は要求を始めたページがどこであっても宛先のサイトの Cookie として付いていきます。サーバから見ると、本人が自分の画面で押したボタンと、別サイトのページが勝手に送らせたフォームは、同じ Cookie を持った同じ形の要求です。

ブラウザは「どこから来たか」を教えてくれます。しかし「本人が望んだか」は教えてくれません。そこでサーバは、別サイトのページには作れないものを要求の中に要求し、自分で照合します。作れない理由は2つあります。

1つは読めないこと。CSRF トークンはサーバが発行して自分の画面に埋めた乱数です。別オリジンのページは b.test に要求を送ることはできても、その応答を読めないので、画面に埋まった値を知りようがありません。OWASP は CSRF tokens prevent CSRF because without a CSRF token, an attacker cannot create valid requests to the backend server. と書きます。

もう1つは書けないこと。Fetch Standard §2.2.2 は、名前が sec- か proxy- で始まるヘッダと、Cookie・Origin などを forbidden request-header とし、スクリプトから設定させません。

These are forbidden so the user agent remains in full control over them.

Sec-Fetch-Site はこの接頭辞を持つので、値を決めるのはブラウザだけです。OWASP はこれを the primary signal for CSRF protection と呼びます。

2つの信号はどちらも、ブラウザの中で動く別サイトのページが作れない、という意味で作れません。相手を変えると成り立たなくなります。

• ブラウザ以外: curl はどんなヘッダでも付けられます。ただし被害者のブラウザの Cookie を持たないので、その要求は本人のものとして扱われません。
• 同じオリジンの中で動くスクリプト: 画面を読めるので CSRF トークンも読めます。OWASP は冒頭で Remember that Cross-Site Scripting (XSS) can defeat all CSRF mitigation techniques! と書いています。

ヘッダの信号には、付かない場合もあります。W3C の Fetch Metadata は、要求先が potentially trustworthy な URL(https や localhost など)でなければ Sec-Fetch-* を付けません。Origin について Fetch Standard §3.2 はたとえば GET・HEAD 以外の要求に使うとしつつ Due to compatibility constraints it is not included in all fetches. と書き、referrer policy によっては値が null になります。OWASP も、Sec-Fetch-* を送らない旧ブラウザがあるとして a fallback to standard origin verification headers is a mandatory requirement としています。

Sec-Fetch-Site の値には same-site もあります。同じ site(scheme + eTLD+1)に属する別オリジン、たとえば兄弟サブドメインからの要求は cross-site になりません。「cross-site だけを拒否する」方針は、同じ site の中にいる相手を通します。