Webアプリの落とし穴に改めて注意

2007.12.17

　今年9月，Gmailにクロスサイト・リクエスト・フォージェリ（CSRF）のぜい弱性が見付かった。ユーザーはメールを盗み見される危険にさらされていた。また，10月にはバッファローの無線LAN製品「AirStation」に組み込まれている設定ツール（Webアプリケーション）に存在するCSRFのぜい弱性が発見された。第三者にAirStationの設定を勝手に書き換えられる可能性があった。

　これらのぜい弱性は，ユーザーがWebアプリケーションにログインした状態で，攻撃者が用意した悪意のあるリンクを誤ってクリックすると，ユーザーが予期しない処理を実行されてしまうというもの。Gmailなら例えば勝手にフィルタ・プログラムを作成して任意のアドレスにメールを転送するなどの仕組みを実現できる。

　グーグルは既にこのぜい弱性を修正済みだが，万が一，利用者のフィルタ・リストに攻撃者が作成したフィルタが存在している場合は，このぜい弱性の影響を受けてしまう可能性がある。ユーザーは，フィルタ・リストをチェックし，不審なものがあれば削除する必要がある。

肝心なのはWebサイトでの対策

　CSRFのぜい弱性は，クロスサイト・スクリプティングと同様にWebアプリケーションにしばしば見受けられる。クロスサイト・スクリプティングがWebサイトに不正なJavaScriptを埋め込んで悪意あるサイトにユーザーを誘導するのに対し，CSRFはユーザーがアクセスしているWebサイトを対象に攻撃を仕掛ける。SNS（ソーシャル・ネットワーキング・サービス），wiki，ブログなどWeb 2.0と総称されるアプリケーションのユーザーが急増する中で，クロスサイト・スクリプティングやCSRFなどWebアプリケーションのぜい弱性を悪用した攻撃は次第に多様化してきている。

　クロスサイト・スクリプティングやCSRFのぜい弱性の責任はWebサイトの運用者にある。にもかかわらず，被害を受けるのはサイトにアクセスしてきたユーザーである。Webサイト，あるいはWebアプリケーションのベンダーは顧客を守るために，ぜい弱性を排除しなければならない。

　そこで以下では，Webアプリケーションに潜んでいるCSRFのぜい弱性を突いた攻撃の手口と基本的な対策を紹介しよう。

知らぬ間にブラウザを乗っ取られる

　Webアプリケーションの中には，セッションIDを使ってユーザーを識別するものがある。例えばSNSのような会員制サービス，Webメール，オンライン・ショッピングなどではよく使われている。このようなサービスにログイン中のユーザーが，意図しない処理を強制的に実行させられてしまうのがCSRFの問題である。攻撃者はメールなどを使って罠のリンクを送り，サービスにログインしている最中に罠のリンクをクリックするようにユーザを巧妙に誘導する。

【修正履歴】CSRFの説明として誤解を招きやすい表現がありましたので，修正しました。（2007.12.18）

　例えば，犯罪者がexample.comという会員制サイトを利用するユーザーAを狙い，パスワードを勝手に変更するケースを考えよう（図1）。

図1●クロスサイト・リクエスト・フォージェリの仕組み
標的とするWebアプリケーションに狙ったユーザーがログインしていることを前提とした攻撃。図中の太線部分が攻撃に関連する部分。

　ユーザーAがサイトにログオンすると，サイトはユーザーAにセッションIDを含んだクッキーを発行し，以後はこのクッキーを使ってセッションを管理する。このとき犯罪者は，example.comのパスワード変更ページにリンクした悪意あるURLを送り，ユーザーAがクリックするように誘導する。URLにはパラメータとして変更後のパスワードが含まれている。

　ユーザーAがこのURLをクリックすると，ブラウザはexample.comのパスワード変更ページにアクセスし，自動的に新しいパスワードを入力する。example.comへのアクセスには既に入手しているクッキーを使うから，サイト側は正規のユーザーと判断して処理を進めてしまう。

　こうして，犯罪者は自身が設定した新しいパスワードを使ってユーザーAになりすますことができるようになる。ユーザーは，気付かないうちに被害に遭ってしまう。

画面遷移を確認すれば穴が見える

　この例の問題点は，実はパスワード変更の画面を見れば分かる。図2の左側の画面のように新しいパスワードだけを入力するようになっていると，CSRFのぜい弱性を抱えることになり，例のように乗っ取られる。

図2●クロスサイト・リクエスト・フォージェリのぜい弱性を回避する方法の例
パスワード変更の場合なら，変更の意思確認として，現在のパスワードなど本人しか知らない情報の入力を求める。

　対策の一つは，図2の右の画面のようにパスワード変更ページで現在のパスワードを要求することである。現在のパスワードは，ほかの手段で漏れていない限りユーザーにしか分からないからだ。ユーザーAに偽の要求となるURLを送っても，現在のパスワードがなければパスワードは変更できない。つまりWebサイト運用者は，重要な処理を実施する直前の画面で正規ユーザーだけが知る情報を要求しているかどうかを確認することで，CSRFのぜい弱性の有無を確認できる。

　CSRF対策はほかにもある。例えばパスワード変更の処理要求を受け付けた後に確認画面を設ける方法。ユーザーが確認ボタンを押さなければパスワードは変更されない。クッキーのセッションIDにひも付けて乱数を生成し，hidden値として処理受付の応答に埋め込む方法もある（図3）。処理を実行するページで，セッションIDとhidden値を照合すれば，CSRFの偽要求を見分けられる。