CSRF
読み：スィーエスアーエフ
外語：CSRF: Cross Site Request Forgeries

　Webアプリケーションにおける脆弱性の一つ。クロスサイトリクエストフォージェリ。
目次
概要
　ある悪意ある仕掛けの施されたサイトのWebページを閲覧したときに、閲覧者の予期せぬ別サイトのスクリプト等が実行されてしまう問題である。
　具体的な方法は書かないが、ある程度スキルがある者なら、外部のCGIを実行させる方法は幾つか予想が付くだろう。
　その機能を悪用し、例えばどこかの掲示板に投稿させたり、何らかのサービスにユーザー登録させたり、といった事がある。
　投稿では、mixiの日記に強制的に投稿する「ぼくはまちちゃん!」問題などが知られる。
　また最近ではmixiの自分のページをURLにすることで、アクセスログ取得のような使い方もなされているようだ。mixiの場合、本名を登録しているケースも少なくないため、問題は深刻と思われる。
特徴
対策
　ユーザーがこの攻撃から身を守るのはほぼ不可能であるが、サービス提供者はこの攻撃を回避するよう、CGIプログラムを作成することができる。よって、こういったサービス(mixiなど)を提供する際には、この攻撃を受けないよう、対策を取るべきだと考えられる。
　mixiのように、ログインを前提としたサービスであれば、セッション管理用に乱数が使われることが多いが、これを上手に活用することで、ほぼ、CSRFを防ぐことが可能である。
対策方法
　以下は、サービス提供側の対策方法を述べる。
セッションIDを使う
セッションIDの設計方法
　サービスは、ログインした際に乱数等で数列や文字列を作り、それをセッションIDとしてCookieで持ち回して使う。
　乱数数列だけでもかなり攻撃に強くなるが、更にハッシュ関数を併用すれば、乱数を使っていることさえ分かりにくくなる。
　IDは乱数でなくても良い(例えばkey + user ID + yyyyMMddhhmmssのような文字列のハッシュ値など)が、外部から容易に推察可能なものは避けねばならない。
　この数列や文字列はできるだけ桁数を多くすると、偶然のなりすましを防ぐことができる。
セッションIDの発行と寿命
　このセッションIDは、発行以降ログアウトするか一定の寿命を迎えるまで、サービスを利用するパスワードとなる。
　このセッションIDは、必ずログインしてから作成し、発行する必要がある。さもないと、セッション固定攻撃の対象となる。
実例からの検討
日記などの投稿
　「確認画面」を作れば防げる、などとする対策案を提示する者がいるが、無駄である。攻撃者は、その次の実行画面に直接攻撃を加えるからである。
　そこで、機能は次の3画面で構成することにする。
  1. 最初の画面(日記なら、その文章を入力するフォーム)
  2. 確認画面(これで登録します。よろしいですか?)
  3. 終了画面(登録しました)
　述べる迄もないが、CGIが動くのは、1と2の間、2と3の間である。
攻撃スタイルを検討する
　通常の攻撃スタイルは、いわゆる1パスであり、あるタイミングでCGIに直接データを送ることで実現する。
　従って上述の例であれば、攻撃者は2→3の段階のCGIを、ターゲットとするだろう。セキュリティ強化は、この段階を重点的に行なうこととする。
正当性の確認
　そこで、最後の2→3の段階で、その投稿が本当に本人からの要求であるかを確認する。
　具体的には、画面2ではセッションIDをinput要素にhiddenで含め、処理系はこのセッションIDと、Cookieから与えられるセッションIDが一致するかを確認する。異なる場合は、投稿を受け付けないようにする。
　この方法だけで、CSRFはかなり防げる。
2パス攻撃について
　但し、1→2を実行してセッションIDを得たあと、更に2→3を実行するような、2パスの攻撃は避けられない。
　こういった悪質極まるセッションハイジャックには対応するのは、かなり難しいと思われる。それと同時に、これを全自動で行なう処理を作るのもまた、かなり難しいと思われる。
　そこで完全な対応ではないが、攻撃側実装を困難にするため、少なくとも画面1にはセッションIDは含めないようにする。
　セッションIDを得るためには少なくとも画面2を得ねばならないとすると、画面1→2の間のCGIで、状況に応じた何らかの対応をすることも可能となるだろう。
再検索