「ぼくはまちちゃん」 ――知られざるCSRF攻撃：Security&Trust ウォッチ（33）

　ある日、大手SNS（Social Networking Site）のmixiの日記にこのような書き込みがあった。それも1人だけでなく、同日に数多くのユーザーの日記に同じ文面が掲載されていた。

　これは、単にこのような文章がはやり、ユーザー自身が意図して掲載したのではなく、ある仕掛けによってユーザー自身が気付かないうちに引き起こされた現象なのである。その仕掛けとは、CSRF（Cross-Site Request Forgeries）と呼ばれる攻撃手法の一種だ。

CSRFとは

　CSRFという手法は、本来受け付ける必要がない（拒否すべき）外部のWebページからのHTTPリクエスト（POSTやGET）によって、Webサイトの何らかの機能が実行されるというものである。攻撃として利用されるCSRFの特徴としては、ログイン認証を必要とするWebサイトが攻撃対象となっていることである。

　「はまちちゃん」事件のように、ユーザーの権限をもってログインしなければできない日記への書き込みがそれに該当する。削除機能や編集機能、退会機能などを実行されてしまう恐れもある。CSRFという名前はCross-Site Scripting （XSS）と似ているが、別の攻撃手法である。

CSRFは本来受け付ける必要がない外部からのリクエストを受け付けてしまう脆弱性を利用した攻撃手法

　CSRFでは、仕掛けを埋め込んだWebページを正規ユーザーが表示することでターゲットとなるWebアプリケーションにリクエストを送る。CSRFの主なターゲットはログイン認証が必要となるWebサイトなので、正規のアカウントがなければ当然Webアプリケーションを実行することができない。

　しかし、ログイン認証が必要なWebサイトの多くは、ログイン認証手順を省くためにCookieを利用して自動ログイン機能を提供している。1度ログイン認証を行えば、その認証済みのセッションがしばらくの間は有効になっている。そのセッションの有効期限は短ければ5分程度で、長いところは永久に有効なところもある。それ故、CSRF攻撃が成立してしまう。

　CSRFは、ログイン不要なものにも有効な攻撃である。例えば、アンケートフォームや問い合わせフォームなども攻撃できる。対象がショッピングサイトであれば、勝手に何か購入されてしまうかもしれない。最近では、ルーターなどのネットワーク機器や、サーバーの各種設定をWebブラウザ経由で行えるものが増えているので、これらもCSRF攻撃の対象となり得る。

CSRFを巧みに実行させるわな

　CSRF攻撃を発動させるためには、外部のWebページかHTML形式のメールなどのHTMLテキストが必要となる。いかにも怪しげなことが書いてある投稿用Webフォームが設置してあっても、誰も“送信”ボタンをクリックしないだろう（と信じたい）。

　ユーザーに“送信”ボタンをクリックさせるために、次のようなテクニックを併用していることが多い。これらは、「はまちちゃん」事件でも使われていた手法である。

●フィッシング詐欺のように

　言葉巧みにクリックしたくなるような文言を並べてユーザー自身にクリックさせる。「はまちちゃん」の場合、「【発見】mixiの裏技」という見出しと、「↓オイオイ、すげぇぜ…」という本文だけで攻撃用ページへのリンクをクリックさせていた。また、XSSを利用して本当のWebサイトのように見せかけるといった悪質な手法も併用可能だ。

●URLのリダイレクト

　「はまちちゃん」事件では、攻撃用ページへのリンクを無害なGoogleへのリンクのように偽装していた。Googleから攻撃用ページへとリダイレクトさせていたのである。

●JavaScriptによる自動送信

　mixiの正規ユーザーが攻撃Webページを読み込んだ瞬間に、JavaScriptによって攻撃フォームを自動的にクリックさせられていた。また、画像を表示するためのIMGタグを悪用する方法もある。

Webサイト運営者側のCSRF対策

　効果的なCSRF対策を講じるためには、Webアプリケーションのプログラムで行う必要がある。多くの対策が考えられるが主なものを次に挙げておく。

●Cookieを使ったセッションの追跡

　これは、運営者側が想定したページ遷移どおりに利用者がページを移動していることを確認するための方法である。

　まず1ページ目で渡すCookieの中に、セッションIDなどの使い捨ての一意な文字列を追跡用として含ませる。そして、2ページ目の下記のようにフォームに先ほど渡したCookieの文字列を含ませる。

<input type="hidden" name="sessionid" value="前ページで渡した追跡用の文字列">

　Cookieの中身と受け取ったリクエストの文字列の両方が一致するのを確かめることで、利用者が正しいページから遷移していることを確認する。もちろん、その文字列がサーバー側で発行した有効な文字列であることも確かめる必要がある。

●リファラーで発信元をチェック

　HTTPリクエストを受けたとき、そのリクエストがどこのWebページから発行されたものかを示すリファラー（REFERER）と呼ばれる情報を得ることができる。この情報を活用し、本来意図したWebページ以外からのリクエストを拒否することで、CSRFによる外部からのリクエストを防ぐことができる。

　ただし、ユーザーがリファラー情報を出力しないブラウザを使っている場合、このチェックを導入すると正当な操作でも受け付けなくなってしまう。

　懸念されるリファラー情報偽装に対する問題だが、以前はリファラー情報を発行するのは攻撃を踏んでしまった自分自身なので、リファラー情報を偽装する動機がなく、この対策は安全であるとされていた。しかし、Flashのアクションスクリプトを利用することではRefererヘッダーを自由に作成できてしまうため偽装できてしまう。よって、この対策だけでは安全と言えなくなった【注】。

●チェックコードを利用

　これは組み込むには少しの手間がかかるが、かなり効果的である。正式名称を何と呼ぶのか知らないが(筆者追記：「CAPTCHA」というそうだ)、フォーム入力時の画面で画像を使ってランダムな文字列を表示し、それをユーザーに手入力させるという方法だ。この方法は、ユーザーの明確な入力を求めるので、エンドユーザーには少し手間であるが、CSRF対策としての効果は高い。

上のような画像を表示し、ユーザーに「atmarkit」と入力させる

　上記の対策より効果は劣るが、実装する手間が少なく、何もしないよりはマシな方法も挙げておく。

●GETよりPOST

　HTTPリクエストを送る方法にはGETとPOSTがある。GETはURLにすべての情報を載せて送るリクエスト方法である。そのため、GETによるリクエストの受付を行っていると、POSTに比べて多くの攻撃手段を提供してしまうことになる。ただし、GETよりPOSTの方がまだマシだというだけで、POSTの場合でも攻撃手段はいくつも存在する。

●確認画面の追加

　例えば“削除”という機能を実行するときに、“削除”ボタンを押したら即実行するのではなく、「削除しますがよろしいですか？」といったWebページを1枚挟むことによって、ユーザーの確認を促す方法だ。気休め程度の対策であるが、GETのような単一のリクエストには効果がある。しかし、確認画面を含め複数ページに渡ってリダイレクトされる可能性もあり万能ではない。

エンドユーザーのCSRF対策

　常に「CSRFを巧みに実行させるわな」に挙げた項目を疑ってかかれといいたいが、そんなことをしていては、まともにWebページを見ることができなくなってしまう。残念ながら、エンドユーザー自身にできるCSRF対策は、小まめにログアウトし必要なときにログインするという手段ぐらいしかない。しかし、この方法ですらエンドユーザーにとってはWebの利便性を十分に損なうものなので、実際に対策するユーザーは少ないだろう。

　Webサイトの運営者はエンドユーザーに期待せず、十分にCSRF対策を行っていただきたい。また、読者の皆さんがCSRF攻撃が可能になっているWebサイトを発見した場合には、Webサイトの管理者なり、IPAなりに適切に報告して欲しい。報告前に掲示板などで公にするのは、得策ではないので気を付けていただきたい。