CSRFトークンが「非セッションクッキー」と紐づく脆弱性（続編）：サブドメイン経由のクッキー注入による攻撃成立

Hello there, ('ω')ノ

✅ この脆弱性がさらに危険になるケース

CSRFトークンがsessionとは別のCookie（例：csrfKey）に紐づいている場合、 通常は被害者のブラウザ内に攻撃者のトークンを注入できないため、バイパスは困難です。

しかし、次のような「外部からクッキーを設定できる仕組みが存在する」と話は変わってきます：

🎯 攻撃が成立する追加条件

攻撃者が自分でログインして取得した：
- csrfKey=<攻撃者トークンのキー>
- csrf=<攻撃者トークンの値>
被害者のブラウザに、攻撃者が自分のcsrfKeyをセットできる手段がある

✅ クッキーを設定する仕組みの例

同一ドメイン内の他サービスからSet-Cookieが使える
被害者を誘導して、document.cookieでJavaScript経由で書き換えられる
staging.normal-website.com などのサブドメインが、 secure.normal-website.com に対して有効なCookieを発行できるような設定になっている

📌 注意点（セキュリティ設計の罠）

Cookieのスコープ（ドメイン） が .normal-website.com のように広く設定されていると、別サービスの脆弱性が本番環境のCSRFトークン検証をバイパスする武器になる

💥 実際の攻撃シナリオ（複合技）

攻撃者が自分のCSRFトークン＋csrfKey Cookieを取得
staging.normal-website.com/set_cookie?csrfKey=XXXX などの機能を使い、被害者のブラウザにCookieをセット
被害者に以下のHTMLを開かせる：

<form method="POST" action="https://secure.normal-website.com/email/change">
  <input type="hidden" name="email" value="attacker@evil.com">
  <input type="hidden" name="csrf" value="attacker-token">
</form>
<script>
  document.forms[0].submit();
</script>

被害者のセッションと、攻撃者のトークンが組み合わさってCSRF攻撃が成立する

✅ 本来あるべき対策

項目	正しい設計
トークンはセッションに直接紐づける	`session['csrf_token']` と一致照合する
トークンはJavaScriptで書き換えできない	`HttpOnly`属性を付けてJSからの操作を禁止
サブドメイン間でCookie共有を許さない	ドメイン指定を`secure.normal-website.com`に限定する
アプリ間でCSRFロジックを統一する	フレームワークを跨がないか、検証方式を統一する

✅ まとめ

この脆弱性は、単独では難しい攻撃のように見えても：

同一ドメイン内の他システムを悪用できると攻撃が成立する
攻撃者は意図的に別の場所からCookieをセットして、CSRFトークンのスプーフィングが可能

CSRF保護は「値の検証」だけでなく「誰のクッキーか」を見て初めて安全です。

Best regards, (^^ゞ

Shikata Ga Nai

Private? There is no such things.