CSRF対策を「フレームワークが勝手にやってくれる」で止めない──トークンの標準化、重要な操作の洗い出し、管理画面まで含めたレビューと顧客への説明の型

この記事は、CSRF対策（クロスサイト・リクエスト・フォージェリ対策）を、制作会社の社内標準とレビューの型にする方法を扱います。

「ログインしている人が、自分の意思と関係なく操作させられる」

CSRFは、説明が難しい脆弱性です。
SQLインジェクションやXSSに比べて、顧客にも、社内の若手にも、イメージが伝わりにくいのです。

一言で言えば、ログイン中の利用者が、別のページを開いただけで、本人の意図しない操作（登録内容の変更、投稿、設定の変更など）をさせられてしまう問題です。

伝わりにくい脆弱性ほど、「たぶん大丈夫」で放置されます。
だからこそ、会社の標準として、決めておく価値があります。

CSRF対策とは、「重要な操作は、本人が自社の画面から送ったものだけを受け付ける」仕組みを、全案件で同じ方法で入れることである

黒字化の外科医です。CSRF対策を、制作会社の標準とレビューの型として解剖します。

社内標準にすべき理由は、三つあります。

第一に、対策が必要なサイトは、ログイン機能を持つサイト全般だから。
IPAの「安全なウェブサイトの作り方」は、特に注意が必要なサイトとして、決済などの金銭処理があるサイトに加え、管理画面、会員専用サイトなど、ログイン機能を持つサイトを挙げています。
CMSで作ったコーポレートサイトにも、管理画面はあります。

第二に、正しい方法は、すでに決まっているから。
IPAは根本的解決として、処理を実行するページをPOSTでアクセスさせ、事前に作った秘密の値（トークン）を埋め込み、一致したときだけ処理する方法などを挙げています。
OWASPのCSRF対策のチートシートも、まずフレームワークに組み込みのCSRF対策があるか確認して使うこと、状態を変える操作にGETを使わないことを勧めています。

第三に、他の対策が崩れると、CSRF対策も崩れるから。
OWASPは、XSSがあるとCSRFの対策はすべて破られ得ると注意しています。CSRF対策は、XSS対策と一緒に標準化して初めて意味を持ちます。

今すぐ試せる：「重要な操作」を洗い出すプロンプト

私はWeb制作会社の経営者です。顧客サイトのCSRF対策を確認するため、
「本人の意図しない実行が起きると困る操作」を洗い出してください。

【前提】
・サイトの種類（コーポレート／会員制／EC／予約 など）：〔　　〕
・ログインがある画面（管理画面、会員ページなど）：〔　　〕
・使っているCMS・フレームワーク：〔　　〕
・自作・改修した機能：〔　　〕

1. ログイン後に行える操作を、すべて一覧にする。
2. そのうち、データの変更・送信・削除・設定の変更にあたる操作に印を付ける。
3. 印を付けた操作ごとに、確認すべき項目（POSTか、トークンの確認があるか、フレームワーク標準の仕組みを使っているか）を表にする。
4. 特に重要な操作（パスワード変更、メールアドレス変更、決済、権限の変更）を、別に挙げる。

攻撃の方法や再現手順は書かないこと。

CSRF安全標準工場：ルール、レビュー、説明文

社内標準の型

【重要な操作の社内標準】第〇版

1. データを変更・送信・削除する操作は、POSTで受ける（GETで状態を変えない）
2. 重要な操作には、トークンの確認を入れる
   フレームワーク・CMSに組み込みの仕組みがあれば、それを使う（自作しない）
3. 組み込みの仕組みを無効にする設定は、原則禁止。使う場合は承認と記録
4. パスワード・メールアドレスの変更、権限の変更などは、
   実行の直前にパスワードの再入力を求めることを検討する
5. 重要な操作が行われたら、登録メールアドレスに通知することを検討する
6. セッションのCookieには、SameSite 属性を設定する（補助の対策として）

4はIPAの根本的解決の一つ、5はIPAの保険的対策です。
6について、OWASPは、SameSite は多層防御として有効だが、多くの場合、本来のCSRF対策の代わりにはならないとしています。SameSite だけで済ませないことを、標準に明記してください。

納品前レビューの確認項目

□ ログイン後の「変更・送信・削除」の操作を、一覧にしたか
□ 一覧のすべてが、POSTで受けているか
□ 一覧のすべてで、トークンの確認（または組み込みの仕組み）が効いているか
□ 組み込みの対策を無効にしている箇所がないか、設定を確認したか
□ 自作・改修したフォームや、Ajaxの送信も対象に入れたか
□ 外部のフォーム作成ツールを使う場合、その対策の有無を確認したか
□ 重要な操作の通知メールの有無を、顧客と決めたか
□ レビューした人・日付・結果を残したか

自作のフォームと、画面を移らずに送信する仕組みは、組み込みの対策の外に出やすい場所です。改修の差分を、必ず一覧に足してください。

問い合わせフォームそのものの安全設計は、第1弾で扱っています。

▶ 問い合わせフォームのセキュリティは「保存しない設計」から──通信・スパム対策・送信先・ログの5つの線と、納品前の確認表

顧客への説明文（例）

本サイトの管理画面・会員ページで行う、登録内容の変更などの操作には、
IPA「安全なウェブサイトの作り方」の根本的解決にあたる対策
（本人の画面から送られた操作だけを受け付ける仕組み）を実装しています。
パスワードの変更など重要な操作について、通知メールを送るかどうかは、
運用に合わせてご相談させてください。

構造的なリスク

逆説を指摘しておきます。

「フレームワークの標準の対策を使う」と決めると、社内の誰も、仕組みの意味を説明できなくなることがあります。
すると、不具合が出たとき、原因を調べずに「対策を外せば動く」という判断がされます。

だから、標準には「外すときは承認」と書き、承認する人には意味を説明できることを求めます。教育の進め方は、別の記事で扱います。

▶ セキュリティ教育を社員に続ける制作会社の型──年1回の研修をやめ、12か月の計画、IPAの無料教材、確認テストで「聞いただけ」を終わらせる

よくあるQ&A

Q. ログイン機能のないサイトなら、関係ないのでは？

公開側にログインがなくても、CMSの管理画面があれば対象です。管理者がログインしたまま別のページを開く場面を想定してください。

Q. トークンのエラーで、フォームが送れないと言われた。

画面を長く開いたままにした場合や、キャッシュの設定が原因のことがあります。対策を外すのではなく、エラーの表示と案内の文を整えてください。

Q. 顧客にCSRFという言葉を使ってよいか？

使ってかまいませんが、「本人の意図しない操作を防ぐ仕組み」と言い換えを添えます。言葉だけでは、品質の説明になりません。

最後に

CSRF対策は、説明しにくいからこそ、標準にしておく価値がある脆弱性です。

重要な操作を洗い出し、組み込みの仕組みを全案件で同じように使い、外すときの承認まで決めた会社だけが、管理画面の安全を「担当者の記憶」から「会社の品質」に変えられるのです。

▶ ファイルアップロードの脆弱性は「受け付ける形式」より「置き場所」で決まる──拡張子の許可リスト、名前の付け替え、公開領域の外への保存を社内標準にする設計の型

これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。

#Web制作会社 #CSRF #セキュリティ #脆弱性対策 #管理画面 #社内標準 #制作会社経営 #中小企業 #コードレビュー #品質管理