「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。
クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。
ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。
ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追跡（セッション管理）を行っているはずであり、それをcookieの値を頼りに 行っている場合、そのcookieの値は第三者には予測不能な値が選ばれているは ずである。（でなければ、セッションハイジャックされたり、なりすましログ インされてしまうのだから、CSRF以前の重大な欠陥があることになる。）
最も自然な方式では、ログインごとに発行するランダムな受付番号、つまり 「セッションID」を1個（ないし https:// 専用を含む2個）用いて、どのユー ザからのアクセスなのかを検索して特定する――(A)。この値を十数桁以上の 乱数とすることで、偶然に的中する確率を何億分の1までに小さくしている。
あまり適切ではないが何らかの都合でセッションIDを使わずに、cookieにユー ザIDを入れる方式となっている場合もあるが、それだけでは予測不能とはなら ないので、そうした場合はそのユーザのパスワードのハッシュ値などもcookie に格納して、ページ毎に両方を確認することによって、なりすましされないセッ ション追跡を実現することになる――(B)。この場合の予測不能性は、パスワー ドが予測不能なはずであることに立脚している。
CSRFを防ぐ必要があるのは、Webアプリケーションに対して何らかの恒久的な データ変更を発生させるアクセスとなるページ（登録情報変更、設定変更、退 会処理、注文実行、取り消しなど）である。たとえば、情報を表示するだけの ページには対策が不要、もしくは重要性が低い（後述の「2ページ目」など）。 ショッピングカートへの商品追加などのように、一時的な状態変更を加えるだ けのページに対するCSRF対策の重要性は低めとなる*1。
たとえば住所変更の機能を想定すると、1ページ目で現在の登録情報が入力欄 に埋め込まれて表示され、その入力欄の必要な部分を書き換えてボタンを押す と 2ページ目で確認画面となり、「変更」ボタンを押すと変更が処理されて 3 ページ目が表示されるという構成が多い。ここで、3ページ目に直接外部から ジャンプさせられると、住所を勝手に変更されてしまうことが起きる。
Webアプリケーションに対してデータ変更を処理させるページ（前述の「3ペー ジ目」）の前のページ（前述の「2ページ目」）に以下のHTML要素を含ませる。
<input type="hidden" name="sessionid" value="セッション追跡用cookieの値">
そして、「3ページ目」で、そこに送信されてくるこの値が、cookieのその値 と一致しているかを調べて、一致しているときだけ処理を実行する。
「セッション追跡用cookieの値」には、前述の(A)方式ならばセッションIDの 値、(B)方式ならばユーザIDとパスワード（のハッシュ値など）の両方を格納 し、「3ページ目」でそれぞれの一致を確かめる。
第三者サイトから「3ページ目」へのハイパーリンク（JavaScriptによる自動 POSTを含む）が作られても、一致させる値を予測することは不能であるはずな ので、CSRF攻撃は成功しない。
一致するかを確認するのは「3ページ目」だけでよいのか。そのままでは、 「2ページ目」へのハイパーリンクを作ることはできてしまう。しかしその場 合、被害者は「2ページ目」が現れたところで自発的に「3ページ目」へ進む ボタンを押さない限り被害に遭わない（XSS脆弱性など他の脆弱性がなければ）。
そこでボタンを押してしまいやすいかどうかは、「2ページ目」の画面内容に 依存する。たとえば、「本当に実行しますか？」以外に何も書かれていない 「2ページ目」である場合には、ボタンを押してしまうかもしれないので、 さらに前のページから同様の対策が必要となる。もっとも、ボタンを押すと何 が起きるのかを適切に説明しておくことは、もとより要求されるところである。
（続く）
*1 注文実行時にカー トの内容を確認するように作られているべきなので、そうなっていれば、気付 かないユーザの責任となる。
*2 JavaScriptで自動POSTさせられる。
*3 確認画面の次の実行画面に直接ジャ ンプさせられる。
*4 対策にならない理由 は、Referer:を送信しない設定にしているユーザがいるため。Referer:偽装が 問題となるのは、セッションハイジャック防止や、なりすましアクセス防止の ためにReferer:チェックをする話の場合。攻撃者が被害者の送信するReferer: を書き換えることはできないのだから、CSRFにReferer:偽装は関係ない。
*5 元々あるセッショ ン追跡用の秘密情報を使えばよい。
*6 Session Fixation攻撃によって回避される。
*7 「2ページ目」（引 数を持つ）に対してCSRF攻撃され、続いて「3ページ目」にCSRF攻撃される可 能性があるので、対策にならない。
昨日の「コラムが検閲引っかかりまくり」で触れた＠IT：「ぼくはまちちゃん」 ――知られざるCSRF攻撃が本日より公開しています。 追記:2005/4/27 下記で補足して頂いています。 ・hoshikuzu | star_dust の書斎 - CSRF対策とCAPTCHA ・yoggy’s diary〜せかいのすみっこ..
mixi には入ってないので詳細もわからないし、いちいちはやりものに反応 しているときりがないので静観していたが高木さんの日記に取り上げられているので、 CSRF攻撃のことをちと書いてみる。 http://takagi-hiromitsu.jp/diary/20050427.html#p01 全体的に、わかりやす..
http://takagi-hiromitsu.jp/diary/20050427.html http://www.atmarkit.co.jp/fsecurity/column/ueno/33.html http://www.google.com/search?hl=ja&q=CSRF&btnG=Google+%E6%A4%9C%E7%B4%A2&lr=lang_ja クロスサイトリクエストフォージェリ ( CSRF ) 関連のお..
-[http://takagi-hiromitsu.jp/diary/:title] --「目次」のリンクだけ、はてなダイアリのままです。移行期間中は、有意義だったものを直し忘れているのでは?
CSRF(クロスサイトリクエストフォージェリ)の対策を自分の中で決めてみましたが...
CSRFについて。
「CSRFって何？」って話はGoogleに譲るとして、CSRFの対策について誤解をしていたり、正しくない対処を推奨しているサイトが多い気がします。
とりあえず
googleで「CSRF」で引っかかるサイトの上位に1つずつツッコミ入れてみます。
http://www.s...
クロス サイト リクエスト フォージェリぃ被害者？？
PHPサイバーテロの技法―攻撃と防御の実際ソシム(2005-11)(著)GIJO...
開発者のための正しいCSRF対策 高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 こめんと(2006-03-30) 最近Webアプリ自体組まないんですけど… ...
