Hello there, ('ω')ノ
✅ CSRF（クロスサイトリクエストフォージェリ）とは？
CSRF（Cross-Site Request Forgery） とは、 ユーザーが意図しない操作を、攻撃者が間接的に実行させる Webアプリケーションの脆弱性です。
🔍 別名：セッションライディング、ワンクリック攻撃とも呼ばれます。
🎯 どうやって起こるのか？
CSRFの本質は：
「ユーザーの認証済み状態を利用して、第三者が勝手に操作させる」 ことです。
✅ 例：イメージしやすい攻撃シナリオ
- ユーザーが「銀行のサイト」にログイン済み（セッションクッキー保持）
- 攻撃者が用意した悪意のあるページにアクセスする
- ページ内に次のようなリクエストが自動送信される：
<img src="https://bank.com/transfer?amount=10000&to=attacker" />
- ユーザーのセッションが使われて銀行がリクエストを受け入れてしまう
🛡️ 同一生成元ポリシー（Same-Origin Policy）とは？
Webブラウザは、異なるオリジン（ドメイン・ポート・プロトコル）からの JavaScriptによる読み取りを制限しています（これがSame-Origin Policy）
しかし、リクエストの送信自体は制限されていないため、 攻撃者が送ったリクエストはユーザーのセッションクッキー付きで送られることになります。
→ これが**「同一オリジンポリシーの部分的回避」**と呼ばれる理由です。
🔓 攻撃条件が成立するには？
| 条件 | 内容 |
|---|---|
| ✅ 被害者がログイン済み | セッション有効中（Cookie保持） |
| ✅ 脆弱な機能がGET/POST等で動作 | リクエストで状態変更操作ができる（例：送金、設定変更） |
| ✅ CSRFトークンなどの防御がない | 対策がないとリクエストがそのまま通る |
🎯 まとめ：CSRFは「ユーザーのふりをする」攻撃
- 被害者が自分の意思で送ったように見せかけてリクエストを送る
- 攻撃者がログインセッションを乗っ取るのではなく、悪用する
✅ 対策（概要）
| 対策 | 説明 |
|---|---|
| CSRFトークン | ユニークな秘密値をフォーム等に埋め込み、サーバーで検証 |
| SameSite Cookie | SameSite=Strict or Lax で第三者からのリクエスト拒否 |
| Referer / Origin ヘッダー検証 | 正しい送信元かチェック |
| 認証情報を要求 | 状態変更操作には再認証やCAPTCHAを求める |
「CSRFはユーザーを攻撃者の手先にする攻撃」 この構造を理解することで、脆弱性診断・設計防御の質が一段上がります。
Best regards, (^^ゞ
