1.はじめに
Cookie、セッションとはじまり、前回の記事では、Webアプリケーションの代表的な攻撃である XSS（クロスサイトスクリプティング） についてまとめました。XSSは「ユーザーのブラウザで勝手にスクリプトを実行される」攻撃でしたね。
本記事では、Webアプリケーション向けの代表的な攻撃として、 CSRF（クロスサイトリクエストフォージェリ） とは何か、どのような仕組みで攻撃が成立するのか、どう防ぐべきかについてをまとめます。
2.CSRFとは？
CSRF（Cross-Site Request Forgery） とは、 ユーザーが意図していないリクエストを、攻撃者がユーザーの代わりに送らせる攻撃 のことです。特徴は、大きく次の2点です。
- ユーザーは「攻撃されたことに気づかない」
- 攻撃者は「ユーザーのログイン状態を悪用する」
つまり、 ログインしているあなたの権限を使って勝手に操作される 攻撃です。怖くないですか。
3.CSRFが起きる仕組み
CSRFの典型的な流れは、次の通りです。
- ユーザーが銀行サイトやSNSにログインする
- ブラウザにセッションID（Cookie）が保存される
- ユーザーが攻撃者の用意した悪意あるページを開く
- そのページが「銀行サイトに送金リクエスト」を自動送信する
- ブラウザは“自動的に”セッションIDを送信する
- サーバーは「ログイン中のユーザーの操作」と誤認する
- 不正な操作が実行される
ここで重要なのは、Cookieは 同じドメインへのリクエストなら自動で送信される という点です。攻撃者はこの仕組みを悪用します。
4.CSRFで何ができてしまうのか
CSRFが成立すると、攻撃者はユーザーの権限で操作することができます。代表例は次の通りです。
- SNSで勝手に投稿される
- メールアドレスやパスワードを勝手に変更される
- ECサイトで勝手に商品を購入される
- 銀行サイトで勝手に送金される
ユーザーのアカウントが悪用されるため、恐ろしい攻撃です。
5.CSRFとXSSとの違い
XSSとCSRFはWebアプリケーション攻撃ということで、混同されがちなので、以下の表にまとめます。
| 項目 | XSS | CSRF |
|---|---|---|
| 攻撃方法 | ユーザーのブラウザでスクリプトを実行 | ユーザーに意図しないリクエストを送信させる |
| 前提条件 | 脆弱な画面にスクリプトを埋め込むこと | ユーザーがログイン状態であること |
| 影響 | セッションID盗難、画面改ざんなど | 不正な設定変更、投稿など |
| 原因 | 入力値の無害化不足 | Cookieの自動送信 |
XSSは「ブラウザ乗っ取り」、CSRFは「ユーザーの権限乗っ取り」といったようなイメージです。
6.CSRFを防ぐには？
CSRF対策もXSSと同じく、主にWebアプリケーションの開発者側で行うものです。代表的な対策は次の通りです。
-
CSRFトークン（ワンタイムトークン）の利用
→フォーム送信時に、以下を送信し、サーバー側で一致確認する。攻撃者はこのトークンを取得できないため、不正リクエストを送れなくなる。
①サーバーが発行したランダムなトークン
②ユーザーのセッションに紐づく値 -
SameSite Cookie の設定
→CookieにSameSite=LaxまたはStrictを設定することで、他サイトからのリクエストにCookieを送らないようにできる。近年のブラウザではLaxがデフォルト。
・ Lax：通常のリンク遷移ではCookie送信、POSTなどは送らない
・ Strict：他サイトからのアクセスでは一切Cookieを送らない -
Referer / Origin チェック
→リクエスト元のドメインを確認し、正規のページからのアクセスかどうかを判定する。 -
重要操作前に「再認証」を必須とする
→送金、パスワード変更のような重要な操作などは、実施前に再度パスワード入力を求めることでCSRFを防ぎやすくなる。
7.おわりに
CSRFは、ざっくり、ユーザーのログイン状態を悪用して 意図しない操作 を実行させる攻撃でした。見覚えのない送金は震えますね...。ユーザーとしてもショッピングの利用を終えたらログアウトすることやブラウザのバージョンを最新にする、など基本的な対策は重要です。
もとはと言えば「Cookieってなんやねん。」というところから始まったこのシリーズ。セッション → XSS → CSRF とまとめてきました。気が向いたらSQLインジェクション辺りをまとめてWebアプリケーションセキュリティの全体像を押さえていければと思っています。ありがとうございました！