POSTフォームのCSRF対策兆候とは？CSRFトークンの仕組み・診断基準・対策方法

POSTフォームのCSRF対策兆候とは

POSTフォームのCSRF対策兆候とは、POST で送信するフォームの HTML に、CSRF トークンらしき項目（csrf_token、_wpnonce、authenticity_token など）が含まれているかという、外から確認できる手がかりのことです。

<form method="post" action="/contact/send.php">
  <input type="hidden" name="csrf_token" value="（推測できないランダムな値）">
</form>

CSRF（クロスサイト・リクエスト・フォージェリ）は、利用者がログインしたまま別の悪意あるページを開いたときに、そのページから自治体システムへ勝手にリクエストを送らせ、本人の意図しない登録・変更・送信を実行させる攻撃です。代表的な対策は、フォームに推測できない秘密のトークン（CSRFトークン）を hidden 項目として埋め込み、サーバー側で照合する方法です。

この診断項目は、トップページの HTML に POST フォームがある場合に、CSRF トークンらしき文字列が HTML 内に見えるかどうかを確認します。外から見えるのは「兆候」だけであり、実際にサーバー側で検証しているかまでは分からないため、見つからない場合も「× 要改善」ではなく「△ 要確認」にとどめています。

CSRF攻撃の仕組みと対策の考え方

攻撃の仕組み

ブラウザは、別サイトから送信されたフォームでも、送信先ドメインの Cookie を（SameSite 属性の設定次第で）付けて送ります。サーバーが「Cookie のセッションが有効なら処理する」だけの実装だと、攻撃者のページに置いた自動送信フォームで、ログイン中の職員や住民の権限による処理が実行されます。

主な対策（OWASP CSRF Prevention Cheat Sheet）

OWASP ASVS 5.0.0 の要件

ASVS 5.0.0 V3.5 は、3.5.1（L1）で「CORS プリフライトに頼らない場合、機微な機能へのリクエストがアプリ自身から発したものか検証する」こと、3.5.3（L1）で「機微な機能には POST 等の非安全メソッドを使う」ことを求めています。SameSite Cookie は 3.3.2（L2）の要件です。テスト手順としては OWASP WSTG v4.2 の WSTG-SESS-05（CSRF のテスト）があり、弱点としては CWE-352 に分類されます。

IPA の整理

IPA「安全なウェブサイトの作り方」（1.6 CSRF）は、根本的解決として次の3つを挙げています。

1. POST でアクセスさせ、hidden パラメータに秘密情報を入れて照合する。
2. 処理実行前にパスワード再入力を求める。
3. Referer が正しいリンク元か確認する。

また、保険的対策として、重要操作時の登録メールアドレスへの通知を挙げています。

CSRF対策についてよくある誤解

• 「POST にすれば CSRF は防げる」：POST フォームも外部サイトから自動送信できます。POST はトークンを本文で安全に運ぶための前提にすぎません。
• 「HTTPS だから大丈夫」：CSRF は通信の暗号化とは無関係です。
• 「トークンが HTML にあるから安全」：サーバー側で検証していなければ意味がありません。この項目が「○ 問題なし」でも実装の確認は必要です。

Cookie 側の対策は「CookieのSameSite属性」の項目で別に評価しています。このページはフォームの HTML に現れる CSRF トークンの兆候に絞って解説します。

POSTフォームのCSRF対策兆候の診断基準（セキュリティAIチェッカー）

取得対象と方法

• 最終到達ページ（トップページ）の HTML 本文（最大2MB）を解析します。
• <form> 開始タグのうち、method="post"（大文字小文字・引用符の有無を問わない）を持つものがあるかを調べます。
• HTML 全体に、代表的な CSRF トークン名の文字列が含まれるかを調べます。対象は次のとおりです。

判定条件

この項目に「× 要改善（fail）」はありません。HTML の外側（Cookie、ヘッダー検証、サーバー処理）で対策している可能性を否定できないためです。

自治体サイトでの判定例

自治体トップページのフォームは多くが GET の検索フォームのため、対象外が一般的です。問い合わせ・申請・予約のフォームページは個別に診断してください。

診断の限界

• 文字列の有無だけを見るため、無関係な JavaScript 内の「csrf」という文字でも「○ 問題なし」になります。
• 独自名のトークン（例：ticket、hash、my_token）は検出できず「△ 要確認」になります。_token は name 属性の値としてだけ認めるため、id="_token" や JavaScript の変数名だけでは兆候になりません。
• <button formmethod="post"> だけで POST にしているフォームは POST フォームとして数えません。
• Fetch Metadata、Origin 検証、SameSite=Strict のみで防御しているサイトは、安全でも「△ 要確認」になります。
• トークンの予測不能性、セッションとの結び付き、検証の有無は外部から判定できません。

CSRF対策がないとどんなリスクがあるか

• なりすまし申請・設定変更：電子申請や施設予約で、ログイン中の住民の名義で予約・取消・登録情報変更が行われます。
• 管理画面の乗っ取り：CMS にログイン中の職員が悪意あるページを開くと、記事改ざん、管理者ユーザー追加、設定変更が行われ、公式サイトの改ざんに発展します。
• 問い合わせフォームの悪用：トークンも送信回数制限もないフォームは、外部から大量送信や第三者宛ての迷惑送信の踏み台にされやすくなります。

CSRF は CWE-352 として MITRE の「CWE Top 25」に継続して掲載されている代表的な弱点です。

CSRF対策の実装方法（Laravel・Django・Rails・ASP.NET・WordPress・PHP・Next.js）

1. フレームワーク標準の CSRF 対策を有効にする

2. 素の PHP の例

<?php
session_start();
if (empty($_SESSION['csrf'])) {
    $_SESSION['csrf'] = bin2hex(random_bytes(32));
}
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
    $sent = isset($_POST['csrf_token']) ? $_POST['csrf_token'] : '';
    if (!hash_equals($_SESSION['csrf'], $sent)) {
        http_response_code(403);
        exit('不正なリクエストです。画面を再読み込みしてやり直してください。');
    }
    // 処理本体
}
?>
<form method="post" action="/contact/send.php">
  <input type="hidden" name="csrf_token"
         value="<?= htmlspecialchars($_SESSION['csrf'], ENT_QUOTES, 'UTF-8') ?>">
</form>

random_bytes と hash_equals は PHP 7 で利用できます。トークンはセッションに保存し、送信値と一致しない POST は処理せずに 403 を返します。

3. Fetch Metadata による多層防御（Next.js Route Handler の例）

export async function POST(request: Request) {
  const site = request.headers.get("sec-fetch-site");
  if (site && site !== "same-origin" && site !== "none") {
    return new Response("Forbidden", { status: 403 });
  }
  // さらに Origin ヘッダーが自サイトか確認し、トークンも照合する
}

4. Cookie を SameSite 付きにする

# Apache 2.4.x（mod_headers）。PHP なら session.cookie_samesite = "Lax" を推奨
# Cookie の出し方で入るヘッダー表が異なる（CGI・mod_proxy_fcgi は always 側）ため両方に書く
Header edit Set-Cookie "^(?!.*;\s*(?i:SameSite)=)(.*)$" "$1; SameSite=Lax"
Header always edit Set-Cookie "^(?!.*;\s*(?i:SameSite)=)(.*)$" "$1; SameSite=Lax"

proxy_cookie_flags ~ samesite=lax;   # nginx 1.19.3 以降。proxy_pass で中継する応答の Cookie が対象

IIS では URL Rewrite の outbound ルールや、アプリ側（ASP.NET の SameSiteMode.Lax）で設定します。

5. 設定後の確認方法

curl -s https://www.city.example.lg.jp/contact/ | grep -ioE '<input[^>]*type=["'\'']?hidden[^>]*>'
# トークンなしの送信が拒否されるか（自組織のテスト環境で実施）
curl -s -o /dev/null -w '%{http_code}\n' -X POST -d 'name=test' https://test.example.lg.jp/contact/send.php

本番環境への試験送信は業務影響があるため、テスト環境で行ってください。トークンなしの送信が 403 などで拒否されれば、サーバー側で検証している目安になります（拒否の理由が別の入力チェックでないかは、応答内容やログで確かめてください）。

サイトを壊さないための注意点

• 静的HTMLキャッシュ（CDN・CMSの静的書き出し）にトークンを焼き込むと、全員が同じトークンを共有したり期限切れで送信できなくなったりします。トークンを含むページはキャッシュ対象外にするか、JavaScript で取得する方式にします。
• 長時間入力するフォームはセッション切れでトークン不一致になりやすいため、分かりやすいエラーと再入力手順を用意します。
• SameSite=Strict は外部サイトからのリンク遷移時にログイン状態が外れるため、電子申請などでは Lax から始めます。
• 外部決済などのクロスサイトPOSTを受けるエンドポイントは、Fetch Metadata 拒否の例外として個別に設計します。

よくある質問（FAQ）

参考資料

• OWASP Cross-Site Request Forgery Prevention Cheat Sheet
• OWASP ASVS 5.0.0 V3 Web Frontend Security
• IPA 安全なウェブサイトの作り方「CSRF（クロスサイト・リクエスト・フォージェリ）」
• MDN <form> 要素
• CWE-352

「POSTフォームのCSRF対策兆候」と関連する診断項目

• CookieのSameSite属性medium
• パスワードをPOSTで送信critical
• 認証情報の送信先をHTTPS・同一オリジンへ限定critical
• パスワード欄のtype属性critical
• フォーム送信先がHTTPScritical
• パスワードマネージャーに適したautocompletelow
• パスワード欄への貼り付けを許可medium
• 64文字以上のパスワードをHTMLで妨げないmedium