クロスサイト・リクエストフォージェリ(CSRF)
クロスサイト・リクエストフォージェリ(CSRF)
・概要 サービスの利用者に意図しないHTTPリクエストを送信させ、利用者の意図しない処理をサービスに実行させる攻撃 →「利用者の意図したリクエストである」という確認が抜けていると、罠のサイト等を閲覧しただけで、利用者のブラウザから何らかの処理を実行させられる場合がある
〜例〜
・利用者のアカウントによる物品の購入
・利用者の退会処理
・利用者のアカウントによるSNSや問い合わせフォームなどへの書き込み
・利用者のパスワードやメールアドレスの変更
CSRFの脆弱性
・上記のような「重要な処理」の悪用に限られる ・被害者である利用者の個人情報などを盗むことは基本的にはできない (パスワードを勝手に変更させられる場合は、パスワードを用いて個人情報をなどを盗み出せる場合がある)
・CSRF攻撃の例 1. Aさんがexample.jpにログインしている(ログインのセッション情報が残っている) 2. 攻撃者が罠のサイトを用意する 3. Aさんが罠のサイトを閲覧する 4. 罠のJavaScriptにより、Aさんのブラウザ上でexample.jpに対し、新しいパスワードが送信される 5. 勝手にパスワードが変更される → パスワードを勝手に変更されると、攻撃者は変更後のパスワードを知っているため、それを利用して被害者の情報を盗むことができる
CSRFはログイン済みのユーザに、意図しない操作を強制的に実行させてしまう攻撃であるといえる
入力フォームに確認画面がある場合のCSRF攻撃
- hiddenパラメータで受け渡ししている場合
- 入力画面 → POSTで送る
- 確認画面 → hiddenパラメータで送る
- 実行画面
この場合は確認画面がない場合と同じで、実行画面がHTTPリクエストとして値を受け取っているため、上記のように攻撃される
- セッション変数でパラメータを受け渡している場合
- 入力画面 → POSTで送る
- 確認画面 → 値をセッション変数に保存
- 実行画面 → セッション変数から値を取り出す
この場合は2段階の攻撃が必要になる
1. 確認画面に対して値をPOSTしてセッション変数に値をセットする
2. その後実行画面を呼び出す
脆弱性が生まれる原因
- form要素のaction属性にはどのドメインのURLでも指定できる → 罠サイトからでも攻撃対象サイトにリクエストを送信できる
- クッキーに保管されたセッションIDは、対象サイトに自動的に送信される → 罠経由のリクエストに対しても、セッションIDのクッキー値が送信されるので、認証された状態で攻撃リクエストが送信される
対策
・CSRF対策の必要なページを区別する → ECサイトにおける物品購入や、パスワード変更、個人情報編集等の確定画面等
・正規利用者の意図したリクエストを確認できるようにする → 具体的な方法として、以下の3種類が知られている
- パスワードの再入力
- +重要な処理の確定前に、ユーザがパスワードを入力することで、意図したリクエストであることを確認できる
-ユーザの操作が増える
Refereのチェック
- Refereとは、リクエスト元のページのURLを示すHTTPヘッダである
- +Refereをチェックすることで、正規のページからのリクエストか確認できる
-ファイアウォールやブラウザの設定でRefereを抑止している利用者もいる
トークンの埋め込み
- リクエストが正しいものか判断するための文字列をリクエストの中に仕込む
- +第三者に予測不能なトークンを要求することで、CSRF攻撃を防ぐ
- +Refereとは違いヘッダではなくパラメータなので、ユーザ依存で失敗することがない
・保険的対策として、重要な処理の実行後に、対象利用者の登録済みメールアドレスに、処理内容の通知メールを送信することも効果的である → 攻撃自体を防ぐことは出来ないが、もし攻撃を受けた際に利用者がすぐに気づくことで、被害を最小限に抑えることができる
