CSRF対策のやり方、そろそろアップデートしませんか / Update your knowledge of CSRF protection

PHPerKaigi 2024 • Day 1での登壇資料です。
https://phperkaigi.jp/2024/
https://fortee.jp/phperkaigi-2024/proposal/0d0f8507-0a53-46f6-bca6-23386d78f17f
※ Authorizationヘッダーを利用したBearerトークン等の活用については言及していません。

Transcript

1. 2024年3月8日 / PHPerKaigi 2024 • Day 1 合同会社テンマド　山岡広幸 CSRF対策のやり方、 そろそろアップデートしませんか
2. 自己紹介 - 山岡広幸（やまおかひろゆき） - Bluesky: @hiroy.kotori.style - X: @hiro_y - PHPは大学のころ、バージョンは3のころから - 最近はSvelteKitとかも
3. 会社をやっています - 合同会社テンマド - 代表社員／2024年6月で10周年！ - 現在のメンバーは総勢で5名 - PHPエンジニア採用募集中！！
4. お仕事先 - 株式会社イノベーター・ジャパン - 社外CTO／神宮前・柏・茅ヶ崎 - 株式会社GoQSystem - 技術顧問／京橋・岩国・広島 - 広島で勉強会やるぞ…！
5. さて、CSRF （発音: CSRF or “sea-surf"）
6. Cross Site Request Forgery
7. Cross またいだ Site サイトを Request リクエストの Forgery 偽造行為
8. IPAによる情報提供 - 安全なウェブサイトの作り方 - 1.6 CSRF（クロスサイト・リクエスト・フォージェリ） - 共通脆弱性情報データベース - https://jvndb.jvn.jp/ja/cwe/CWE-352.html - 「脆弱なコード例」としてPHPのコードが載っている
9. CSRFの基本構造 出典: https://www.ipa.go.jp/security/vuln/websecurity/csrf.html
10. 雑な解説 - 本来のサイトの正規ページを模倣した 悪意あるサイトの罠ページを用意 - 悪意あるサイトから本来のサイトに向けてリクエスト送信 - 意図しないパラメーターを含む等 攻撃的リクエスト（状態変更）を送ってしまう…
11. 防御方法 1⃣ トークン
12. 古来より伝わる防御方法 - サーバー側で予測不能な文字列（トークン）を生成、 セッションに保存し、トークンをフォームに埋め込み表示 - リクエストの際にトークンを含めるようにする - サーバー側でセッションで保持していたトークンと照合
13. つまりこう
14. Laravelの場合 - CSRF Protection - Laravel 10.x - Bladeテンプレートでは @csrf と書けばOK - <input name="_token"... - VerifyCsrfToken middlewareで検証
15. トークン方式のメリット - 確実に防御することができる - 数多くのフレームワークで採用されている - Symfony、Ruby on Rails、Play Framework等 - （フレームワークを使っていれば）お手軽に導入可能
16. トークン方式のデメリット - （よく考えると）シンプルな実装とは言いがたい - トークンを保管するストレージが必要 - セッション用Cookieを改竄されてしまうと… - （XSS等がある時点でCSRFどころではないのでは…
17. さて、最近の話
18. アップデート していきましょう！
19. このトークのきっかけ - SvelteKitを触っていた - あれ、CSRF対策とかどうするんだろう… hidden項目とか必要じゃないんだっけ？？ - CookieのSameSite属性とかあったような… - よい機会なので調べてみよう！！
20. 防御方法 2⃣ SameSite属性を 指定したCookie
21. CookieのSameSite属性 - 【参考】 Site: 公開接尾辞リスト + 直前のドメイン名 - 指定できる値 - Strict: 同一siteの場合のみ送信 - Lax: 異なるsite間の場合、GETの場合だけ送信 - None: どんな場合でも送信
22. つまりこう
23. ブラウザごとに挙動に差異が… - デフォルト（＝指定しない場合）の挙動が異なるので、 明示的にきちんと指定しよう - Chrome: Laxと同様だが、Cookieセット後2分間は POSTの場合でもCookieが送られる（Lax+POST） - Safari: None。「サイト越えトラッキングを防ぐ」 設定によりそもそも送られないことも
24. SameSite属性利用のメリット - セッション用CookieにSameSite=Laxを指定する だけで防御を行うことができる（Strictでも可） - 異なるsiteからは送信されなくなるから お手軽でよさそう、なんだけど
25. SameSite属性利用のデメリット - 古いブラウザはSameSite属性に対応していない - GETの場合はCookieが送られてしまう（Laxの場合） - そもそもGETで状態変更できるリクエストは… - Cookieを利用しないアプリケーションでは使えない - 認証不要な場合とか
26. さらに中間者攻撃のリスクも - “http://example.com" と “https://example.com" は同一siteなのか問題 - ブラウザによって考え方が違う… - HTTPな経路でリクエストが改竄されてしまった場合、 攻撃を受けてしまう可能性がある
27. SameSite属性利用まとめ - Lax、Strictのいずれかを明示的に指定 - 中間者攻撃への対策としてはHSTSを有効化 （includeSubdomainsの指定を忘れずに） - 防御として、緩和はできるが穴があることがわかった - さて… 🤔
28. 防御方法 3⃣ Originヘッダーを利用
29. Originヘッダーとは - ブラウザがリクエスト時にOriginヘッダーを付与する - https://developer.mozilla.org/ja/docs/ Web/HTTP/Headers/Origin - 同一Origin間のリクエストでは、 GET・HEADの場合は付与されないので注意
30. Originヘッダーを利用した防御 - リクエストのOriginヘッダーの値と サーバー側のホスト情報を照合 - 一致すれば正規なリクエスト、 一致しなければ不正なリクエストとして拒否 - そもそも送られてこなかったら拒否するようにする
31. つまりこう
32. Originヘッダー利用のメリット - 簡単、シンプルな手順で防御が可能 - 古いブラウザにも対応できる - Originヘッダーなしの場合、不正とみなす 最近採用されることが増えている
33. SvelteKitの例 - https://kit.svelte.dev/docs/con fi guration#csrf - https://github.com/sveltejs/kit/issues/72 - 最初はトークン方式（いろいろ）が提案されるが、 Originヘッダーの利用で十分では？と結論
34. Next.jsの例 - How to Think About Security in Next.js | Next.js （Server Actionsに関する記事） - Same-Site Cookieがブラウザで デフォルトで付くから防げるとか 🤔 （指定しようね） - HostとOriginのチェックも追加でやるよ、とのこと
35. Honoの例 - https://hono.dev/middleware/builtin/csrf - https://github.com/honojs/hono/pull/1823 - SvelteKitでの議論を参考に実装した、とのこと - v4も出たし注目のフレームワーク
36. 防御方法 4⃣ Sec-Fetch-* ヘッダーを利用
37. Sec-Fetch-* ヘッダーとは - Sec-Fetch-Dest: fetchするリソースを使う形態 （documentとかimageとかfontとか） - Sec-Fetch-Mode: リクエストの形態 （navigateとかcorsとか） - Sec-Fetch-Site: リクエスト元Originとの関係 （same-originとかcross-siteとか）
38. Sec-Fetch-* ヘッダーを利用 - Sec-Fetch-Siteがsame-originであること - Sec-Fetch-Modeがnavigateであること - Sec-Fetch-Destがdocumentであること - 以上をそれぞれ検証すればよさそう
39. Sec-Fetch-* ヘッダー利用の特徴 - Originヘッダーの利用と同様にシンプルに防御可能 - ただし、ブラウザのサポートが割と最近 - https://caniuse.com/?search=Sec-Fetch- Site - 使えるけど、Originヘッダー利用で必要十分ではある
40. 結局どうすれば いいの？
41. オススメパターン - 2⃣ セッション用CookieにはSameSite属性を指定 - __HOST- pre fi xを付けられるとなおよい - 3⃣ サーバー側ではOriginヘッダーをチェック - 4⃣ 追加として、Sec-Fetch-* ヘッダーもチェック - 送られてきていたらチェックするぐらい
42. でも結局のところ - フレームワークで用意されている方法を使うのが一番 - Web開発ではほとんどの場合フレームワークを使う - 1⃣ トークン方式も全然よいものだよ！！
43. 今回話したかったこと （おまけ）
44. エンジニアとしての心がけ - 使っているフレームワークのことをよく知ろう - 使い方も大事だけど、仕組みに興味を持ってほしい - その上で、それ以外のやり方がないか調べよう - 異なる言語・フレームワークを触るときにきっと役立つ
45. ありがとう ございました！