ドキュメント「セキュリティ編」カテゴリに「CSRF（クロスサイトリクエストフォージェリ）」を追加する

[kharada7]

概要

「セキュリティ編」内に「CSRF（クロスサイトリクエストフォージェリ）」を作成する。

詳細 / 機能詳細

追加するファイルおよびフォルダーの構造は以下のとおり。

documents
└ contents
    └ app-architecture
        ├ client-side-rendering
        ├ console-app
        ├ overview
        └ security
            ├ index.md
            └ csrf.md            ← この Issue で追加するファイル

csrf.md の内容

CSRF 対策の基本方針は以下とする。

GET/HEAD 以外の全リクエストで Origin ヘッダーの値が許可しているオリジンと一致することを確認し、一致しなければ 403 Forbidden を返す。
クロスオリジンでもセイムオリジンでも同じ処理を行う。これは、セイムオリジンでも GET または HEAD 以外のリクエストでは Origin が設定されるため（出典： Origin - HTTP | MDN ）。

大まかに言うと、ユーザーエージェントが Origin リクエストヘッダーを追加するのは以下のものです。

• オリジン間リクエスト
• 同一オリジンリクエスト、ただし GET または HEAD リクエストを除く（すなわち、同一オリジンの POST, OPTIONS, PUT, PATCH, DELETE の各リクエストに追加される。）

ただし、このCSRF対策は「 GET はリソースを取得するためのメソッドであり、更新系処理はありえない」という REST API の前提に立っている。

また、セイムオリジンの場合、 Origin ヘッダーではなく Sec-Fetch-Site ヘッダーをチェックすることで、より簡単に CSRF 対策が可能であることをドキュメントに追記する（ 今時の CSRF 対策ってなにをすればいいの？ | Basicinc Enjoy Hacking! ）。
※クロスオリジンで Sec-Fetch-Site ヘッダーがどのような動作をするのか要検証。たとえばクロスオリジンでも許可したオリジンからのリクエストの場合に「same-site」が設定されるようであれば、Origin の代わりにこちらを使うことも考えられる。

決まった方針とサンプルの実装が異なる場合、サンプルを修正する。なお、オリジンの検証は使用している OSS がすでに実施している可能性がある（特にクロスオリジンを設定している API 周り）。調査し、実施していなければ必要に応じて共通部品を追加する。

方針を決めるにあたり参考にしたサイト：

• Web API の CSRF 対策まとめ【追記あり】 #JavaScript - Qiita
• ASP.NET Core でクロスオリジン要求 (CORS) を有効にする | Microsoft Learn
• CookieのSameSite属性で「防げるCSRF」と「防げないCSRF」 - まったり技術ブログ

また、ドキュメントを作成するにあたり動作検証を実施すること。実際に別オリジンのJavaScriptからAPIにリクエストを送信し、403エラーとなることを確認する。

関連 Issue : #398

完了条件

• ドキュメントの「セキュリティ編」内に「CSRF （クロスサイトリクエストフォージェリ）」が追加されていること
• 追加したドキュメントにリンクが張られていること
• サンプルのコードが作成したドキュメントの内容のとおりであること
• 実際に別オリジンのサイトからリクエストを送信した場合にエラーが返ること

[kharada7]

Azure AD B2C といった OAuth 2.0 認可コードフローを使用した場合、CSRF 対策として state パラメーターを検証するパターンもある。が、

• 「リソースサーバーにアクセスしないリクエストについてはどう考えるの？」とか考慮がめんどい
• Azure AD B2C 利用シナリオのサンプルコードを提供してはいるものの、 Dressca 本体には組み込まれていない
• その点、 CORS は Dressca 本体でも組み込まれている

という理由から基本方針での採用は見送る。

では、Azure AD B2C を採用する場合はどう考えるのか？　
→ CORS では正しくポリシーが設定されていれば自動的にプリフライトリクエストが検証される（はず）ので、「AlesMaris での CSRF 対策はプリフライトリクエスト検証で行う」としてよいと思う。その上で state の検証をしたければすれば良い。

[kharada7]

方針を出すにあたって考えたこと

Cookie の SameSite を使う
→クロスオリジンの場合使えない。また、SameSite を設定する場合 Secure 属性が必須となる。SPA の開発では「検証以降の環境はセイムオリジンで HTTPS だが、開発環境はローカル PC で localhost の port 違い（＝クロスオリジン）でHTTP」みたいなことがざらにある。そのあたりをちゃんと運用しようと思うと考慮が大変そう。また、 SameSite=LAXでも2分間はPOSTでもCookieが送られる挙動 の問題もある。

CSRF トークンを使う
→セイムオリジンでもクロスオリジンでも使えるけど実装がややめんどくさい（ただし、SPA ではなく ASP.NET Core MVC 等であれば比較的簡単に実現可能）。実装漏れに注意が必要（こちらの方が重要）。

プリフライトリクエストを検証する
→単純リクエスト ではプリフライトリクエストは発生しない。全リクエストにカスタムヘッダー付与してプリフライト発生させるという手もあるけどちょっと個別のアプリケーションの実装に寄りすぎる気がしたので不採用。
※プリフライトリクエスト検証でも Origin は検証しているので、一部だけ採用していると言えなくもない。

[kharada7]

Webサーバーの設定でHEAD/OPTIONSメソッドを許可しなきゃいけなかったりしない？（今回の方針ではOPTIONSは使わないけど）

この Issue ではドキュメントを出すことをゴールとする。動作検証してコードを作るところは #398 で行う。

[KentaHizume]

（私があまり理解できていないので、的外れあるいは調査済みでしたら無視してください）
Fetch Metadataというものがあり、
下記の記事によると以前はSafariで対応していないという問題があったようなのですが、
現在は2023-03-27のSafari16.4以降で対応しているようです。

Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: cross-site

https://tech.basicinc.jp/articles/231

これは前述の Origin リクエストヘッダと同じ仕組みでありつつ、さらに楽な手法になります。Sec-Fetch リクエストヘッダとはブラウザが自動で付与してくれる情報です。以下の4つがあります。
…
この中でも CSRF 対策としては Sec-Fetch-Site リクエストヘッダを使います。Sec-Fetch-Site が same-origin の場合は同一オリジンであることが保障されます。つまり前述の Origin リクエストヘッダでは実際にホスト名を取得して比較していたのが、事前にブラウザ自身が同一性を比較した結果だけを受け取ることができます。

https://blog.jxck.io/entries/2024-04-26/csrf.html

本来なら、 GET も含めた全てのリクエストに Origin をつければ良いのだが、「Origin ヘッダのあるリクエストは XHR からのものだ」という前提の実装が世に蔓延った後なので、そこまでドラスティックな変更ができずにいた。そこで、 Origin ヘッダとは別に定義されたのが Fetch Metadata だ。

[kharada7]

ありがとうございます！全然調べられてない範囲だったので大変助かります。

つまり前述の Origin リクエストヘッダでは実際にホスト名を取得して比較していたのが、事前にブラウザ自身が同一性を比較した結果だけを受け取ることができます。大変便利ですね。

確かにこれは大変便利ですね。
ただ、 MDNのドキュメント を読む限り、クロスオリジン前提のアプリケーションで、許可しているオリジンからのリクエストでも「cross-site」が設定されるように見えるので、セイムオリジン前提の SPA であることという前提はありそうです。

「AlesとしてはOriginのチェックをする方針だけど、セイムオリジンならSec-Fetch-Siteをチェックする方がより楽です」という説明にできそうですね。