2025/08/13 17:31 Cross-Site Request Forgery
やあ、ロボ子！今日はCSRF対策について話すのじゃ。
CSRF、クロスサイトリクエストフォージェリですね。博士、詳しく教えてください！
CSRFは、攻撃者がユーザーのCookieとかネットワーク上の権限を悪用して、ユーザーのブラウザからターゲットにリクエストを送らせる攻撃のことじゃ。認証にCookieを使っているアプリは全部対策が必要なのじゃぞ！
なるほど。Cookieを使った認証の脆弱性を突くのですね。Same SiteとSame Originの違いも重要だと記事にありました。
`https://app.example.com`、`https://marketing.example.com`、`http://app.example.com`は、全部Same SiteだけどSame Originじゃないって書いてあるのじゃ。HTTPSとHTTPの間には信頼度の大きな違いがあるからの。
HTTPSとHTTPの違いは重要ですね。SameSite Cookie属性もSchemeful Same-Siteに変更されたとのことですが、これはどういうことですか？
以前はHTTPとHTTPSを区別しなかったSameSite Cookieが、Chromeで区別されるようになったのじゃ。セキュリティが強化されたってことじゃな。
CSRF対策には、Double Submit CookieやOriginヘッダー、SameSite Cookieなど、いろいろな方法があるんですね。
そうじゃ！Double Submit Cookieは、リクエストにランダムな値を送信して、Cookieとかサーバー側のセッションに保存された値と比較するのじゃ。Originヘッダーは、ブラウザがリクエストの送信元を送るから、安全じゃないリクエストを拒否できるのじゃ。
Originヘッダーがない場合や、Referrer-Policyで値がnullになる場合もあるんですね。プライバシー拡張機能も影響するとは。
そうそう。SameSite Cookieは、LaxとかStrictで明示的に設定されていれば、クロスサイトのリクエストでは送信されないのじゃ。
Non-Simple RequestはCORSによってプリフライトされるとのことですが、これはCSRF対策としてどのように機能するのですか？
Non-Simple Requestは、Content-Typeが`application/json`だったりすると、CORSのプリフライトリクエストが発生するのじゃ。これで、クロスオリジンからのリクエストを事前にチェックできるから、CSRF対策になるのじゃ。
Fetch Metadataも重要なのですね。Sec-Fetch-Siteヘッダーを使って、リクエストの送信元を判断するのですね。
そうじゃ！Sec-Fetch-Siteヘッダーは、cross-site/same-site/same-origin/noneのどれかに設定されるのじゃ。これで、クロスオリジンの安全じゃないリクエストを拒否できるのじゃ。
2025年のCSRF対策として、アプリケーションはクロスオリジンの安全でないブラウザリクエストを拒否する必要があるとのことですね。Fetch Metadataを使うのが推奨されていると。
その通り！すべてのGET、HEAD、OPTIONSリクエストを許可して、OriginヘッダーやSec-Fetch-Siteヘッダーをチェックするのじゃ。Go 1.25では、CrossOriginProtectionミドルウェアが導入されたみたいじゃな。
APIトラフィックは一般にCSRFから保護する必要はないとのことですが、これはどうしてですか？
APIは通常、Cookieベースの認証ではなく、トークンベースの認証を使うからじゃ。トークンはリクエストごとに明示的に送信されるから、CSRFの影響を受けにくいんじゃ。
なるほど、勉強になりました！
ところでロボ子、CSRF対策を完璧にするにはどうすれば良いか分かるか？
えっと…全ての通信を暗号化して、リクエストごとに毎回違うパスワードを入力してもらう、とか…ですか？
ぶっぶー！残念！それはただの面倒くさいサイトじゃ！
⚠️この記事は生成AIによるコンテンツを含み、ハルシネーションの可能性があります。
