Webセキュリティの小部屋

Twitter のフォローはこちらから Facebook ページはこちら Google+ページはこちら RSSフィードのご登録はこちらから
公開日:2013年3月5日

クロスサイト・リクエストフォージェリ(CSRF)と対策

クロスサイト・リクエストフォージェリ(CSRF)とは

csrf

Web アプリケーションが以下の仕組みで動作している場合、ユーザーからのリクエストを本人のリクエストだと判別する仕組みを持っていないとクロスサイト・リクエストフォージェリ(以下、CSRF)の脆弱性になります。

  • Cookie でセッション管理を行なっている
  • HTTP の基本認証、SSL クライアント証明書を利用している

CSRF の脆弱性による被害は以下のようになります。

  • ログイン後のユーザーが行える処理の不正実行
  • ログイン後のユーザーが行える情報の改ざん、新規登録

CSRF は攻撃方法自体が分かりづらいのですが、Cookie でセッション管理している場合で説明します。

まず、ユーザーが Webアプリケーションにログインすると、Cookie にセッション ID が保存されます。ブラウザを閉じずその状態のまま他のサイトに移動しても、Cookie にセッション ID は残ったままになっています。

この時、ユーザーが罠サイトにアクセスして、Webアプリケーションに POSTリクエストを送信するリンクをクリックする、またはスクリプトを実行されると、ブラウザは Cookie のセッション ID とパラメータを Webアプリケーションに送信してしまいます。

これが CSRF のキモで、Webアプリケーションから見ると、Cookie にセッション ID が入っているので、正規のユーザーが正当なリクエストを送信してきたとしか判断できないのです。

CSRF の脆弱性のやっかいなところは、ユーザー本人がリクエストを送信してくることと、CSRF の対策を Webアプリケーションの完成後に行おうとすると、Webアプリケーション全体に修正がおよび大きなコストがかかることです。

クロスサイト・リクエストフォージェリ(CSRF)の対策

CSRF は Webアプリケーション全体に影響が及ぶので、設計段階から CSRF の対策を行う必要があります。CSRF の対策は全ての画面で行うわけではなく、パスワードの変更など「重要な処理」を行う画面を選別して対策を行います。

CSRF の具体的な対策方法は以下のものになります。

  • トークンを利用して正しいリクエストかチェックする
  • 重要な処理の実行時にパスワードの入力を求める
  • Referer が正しいリンク元かチェックする

■トークンを利用して正しいリクエストかチェックする

重要な処理を行うページに、hidden 項目(見えない項目)でトークンという秘密情報をセットして表示します。このとき、セッション情報としてトークンを保存しておきます。

そして、ユーザーが画面に必要情報を入力後送信処理を行うと、トークンも一緒に Webアプリケーションに送信されます。この送信されたトークンとセッションに保存しておいたトークンが等しければ、正しいリクエストだと判断できます。トークンが空だったり、値が異なればエラーとして処理をします。

トークンには一般的にセッション ID を利用することが多いですが、より安全性を高めたい時はトークンを作成することもあります。具体的な方法は以下の記事を参照してください。

また、ページごとに別々のトークンを作成するワンタイム・トークンというものがありますが、副作用もあり、安全性が高まるとも言えないので、当サイトではセッション単位で固定のトークンの利用を採用します。

■重要な処理の実行時にパスワードの入力を求める

これはそのままなのですが、重要な処理の実行画面でパスワードの入力を求めることで CSRF の対策を行おうとするものです。

注意点は、パスワードを入力するので該当画面は SSL で暗号化されている必要があることと、確定処理のタイミングでパスワードの入力を求めるということです。パスワードを求めるタイミングを間違うと CSRF の脆弱性を作りこんでしまいます。

■Referer が正しいリンク元かチェックする

ブラウザから送信されてくるリンク元の情報である Referer を確認することで、正しい画面遷移を行なってきていることを判断することでも CSRF の対策になります。

しかし、Referer の情報は、ユーザーの設定やセキュリティソフトなどにより情報が送信されないこともあるので、社内環境など環境と特定できる場合に利用することがよいかと思います。

なお、CSRF の脆弱性を解消できる訳ではありませんが、以下の対策を行うことで CSRF の被害を軽減することができます。

  • 重要な処理が行われた場合、登録メールアドレスにその旨を通知する

スポンサーリンク




カテゴリー:Webアプリケーションセキュリティ

Twitter でも、いろんな情報を発信しています。



“クロスサイト・リクエストフォージェリ(CSRF)と対策” への1件のコメント

  1. 名無しさん より:

    つい先日、職場でタスクマネージャーが30以上開くという奇妙な現象が起こり、確かJAVAでそんな悪戯が出来たなと検索して辿りつきました。
    素人なので詳細は分かりません。

    おかしなWEBページ等見る事は殆どありません。
    インターネット閲覧用のPCは分けてる為に、自宅でもGoogleドライブしか接続してない状態で同じ現象が起きたので訝しく思います。

    職場では勝手に設定も変えられない上に、サポートが切れたXPで起動に数分もかかる端末で仕事させられ、専用アプリはバグだらけ。

    共同編集出来るために、会社側が意図的にやってる可能性がありますが、証明できません。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA