CSRF のメモ
クロスサイトリクエストフォージェリ*1
クロスサイトスクリプティング*2と同様の手法で、正規のユーザに意図しない操作をさせるリクエストを行わせる。最近になって注目されてきたみたい。
ややこしい説明だな。
クロスサイトスクリプト（以下 XSS）はもうお馴染みですね。リンクを踏んだらリンクに含まれた入力値が出力に反映されてしまって、スクリプトやタグが挿入されることで Cookie を盗んだり偽画面を表示させることができるものです。
対してクロスサイトリクエストフォージェリ（以下 CSRF）は、リンクを踏むとリンクに含まれた入力値がサーバに送られるのまでは同じですが、サーバは出力を適切に処理しています*3。
では、CSRF の何が問題か？というと、送り込まれる入力値そのものが「正規のユーザが入力したもの」として取り扱われてしまう、ということなんですね。
これの何が問題かというと、
- 正規のユーザがログイン後に行える操作を偽装できる
- たとえば、WEB メールの送信
- たとえば、商品の購入
- たとえば、SNS 招待メールの発信
- たとえば、エントリの記入やアップロード、削除
- たとえば、退会処理
てなことが最大の問題なんですね。つまり、「本来の画面で正規のユーザが入力したパラメータ」なのか「関係無いリンクに含まれた第三者が準備したパラメータ」なのかを分別していないことが問題の原因になります。
これを、たとえばMETAタグで順番に遷移させながら隠しフレーム等で次々呼び出してこんな操作をしたとしましょうか。
- 犠牲者の会員情報ページの「届け先」を攻撃者が用意した住所に変更する
- 犠牲者に「最新型のホゲホゲ」（オークションや中古転売で稼げそうなモノ）を購入させる
- 犠牲者の会員情報ページの「届け先」をさらに別の住所に変更する
これで、一見して「どこに商品が送られたか」わかりづらくできます*4し、アパートの空き部屋に勝手に送りつけるなどの方法で受け取れば身元も隠せます。
あらかじめクレジット番号を登録しておいて後払いする仕組みのサイトであれば大変な事になるでしょう。*5
他にもこんなことが可能です。最近は設定をブラウザから行うアプリケーションが増えていますが、管理者に HTML メールなどを読ませることができれば、
- FireWall の設定をユルユルにさせる
- ルータの設定をグダグダにさせる
- ウイルスチェッカを停止させる
などの行動が取れますな。
最大の問題は繰り返しになりますが「正規のユーザにできることが第三者にもできるようになってしまう」ことにあります。正規のユーザの意思で入力したパラメータであることを保証しなければなりません。
難しそうですねえ。
最も簡単な対策は REFERER チェック、ですが、乗り越えられる可能性があります。たとえば「はてな」の編集画面には REFERER が表示されていますが、そこに誘導されていったら HTML ヘッダにリダイレクト書かれてて飛ばされた、なんてとき、確か REFERER は最初の編集画面のままだった気がします。*6
そういう場合、再度はてなに押し返されたら対応は難しそうですね。
（注意：はてなにその問題があるかどうかは知りません。たぶん無いと思うんですが。）
あとはワンタイムパスワードのテクニックの流用(?)でしょうか。セッションコードを Cookie だけでなく、たとえば Hidden タグなんかに埋めておいて、セッション変数と比較して一致しなければ操作を認めない、とか。Cookie に頼っていては難しいでしょう。なんせ正規のユーザがいつものブラウザでアクセスしてくるわけですから、ブラウザが自動的に送り出せるものは疑う必要がでてきます。つうか Cookie は疑うよね？セッションハイジャック対策に疑うのが普通でしょ。
あとは必ずチェックコードの入力を要請する方法がありますか。ひみこーどみたいな、画像で乱数を表示させてそれを書き込ませる、といったものですね。スクリプトで大量にアカウントを作成されないように対処した WEB メールなどの新規アカウント作成画面あたりが参考になるでしょう。
実装が面倒そうですが、画面遷移を限定する方法もありますね。セッション変数で画面名を持っておいて、ツリー構造に管理した順番に合わないと遷移できないようにするやりかた。ウィザードリーにあこがれて 3D 迷路をうろつきまわるゲームを作ろうとした事がある人なら感覚がわかると思います。許された遷移しかできないようにしちゃう方法ですね。この場合、呼び出す URL は常に同じになるかと思います。おなじアプレットやスクリプトがセッション変数の値に従って画面を出力する、ということになります。
ただし、これらのテクニックを駆使しても、XSS を併発していれば突破することができます。
また、ログイン操作が必要ない場合であっても問題が起きる事があります。たとえば、「問合せフォーム」に CSRF の問題があった場合、大量の問合せが届くなんて可能性があります。
んー。俺が知ってる範囲は狭いな。なんかいろいろ噴出してる模様。ちゃんと勉強しないとついていけないや('A`)
参考資料への多数のリンクをスターダストさんが集めてくれています。
SpecIII のわかりやすいまとめ
とりあえずグーグル様の検索結果置いておきますね
んー。コレ探すの面倒なんだよねえ。正規ユーザになってからでないと問題の検出ができないし、こっちは正規ユーザになっても大丈夫なのかどうか知りたいわけなんだけどなあ。
