サービスを提供しているイー・マーキュリーでは、この現象について一応の対処は取った模様だ。ただ、技術的な詳細については「ハッキングでもなく、サーバ攻撃やウイルスでもない。ID盗難などの被害は発生していない」という回答のみで、「それ以上はコメントできない」と述べるにとどまっている。
だがある意味、このコメントは正しい。「はまちちゃん」現象は、ウイルスなどの仕業ではないからだ。
正規ユーザーの操作で「意図しない」結果に
URLをクリックすると勝手に日記が書き込まれるこの現象の原因は、Webアプリケーションの脆弱性の一種である「クロスサイトリクエストフォージェリ（Cross Site Request Forgeries：CSRF）」によるものだ。外部からの攻撃やウイルスによるものではなく、Webアプリケーションの実装に起因する問題である。
三井物産セキュアディレクションでWebアプリケーションのセキュリティ検査に携わっている中村隆之氏から得られたコメントによると、CSRFとは「特定の機能を実行するときのHTTPリクエスト（URLや必要なパラメータなど）を攻撃者が推測可能な場合に、攻撃者によって誘導されたユーザーが、意図に反してその機能を実行させられてしまう」という脆弱性だ。IPAとJPCERT/CCが4月19日に行った、2005年第1四半期の脆弱性届出状況に関する説明会でも言及されていた。
「クロスサイト」という単語だけを見れば、Webアプリケーションの脆弱性の1つとして広く知られている「クロスサイトスクリプティング（XSS）」が連想される。確かに、CSRFとXSSには共通点がある。いずれもWebアプリケーションを悪用し、サーバを介してユーザーが被害を蒙ってしまうことだ。
しかし中村氏によると、XSSでは入力値の未チェックやサニタイジング漏れといったアプリケーションの「不備」が狙われるのに対し、CSRFではアプリケーションが備える「機能」そのものが利用されるという。正規ユーザーがログインしている状態で、アプリケーションが備える正しい機能を用いて「意図しない結果」がもたらされるわけだ。
「はまちちゃん」騒動の場合、ユーザーは既にmixiにログインした状態にある。そこで何の疑いも持たずに、エンコードされた文字列とコマンドが仕込まれた（けれど「何だか面白そう」と思わせる説明付きの）URLをクリックすると、勝手に日記が追加されてしまう。というのも、クリックした本人にはそのつもりがなくとも、Webサーバ側から見れば、ログイン済みの正規ユーザーが日記を書き込むためのコマンドを要求したのと同じことだからだ。処理を断る理由はない。
mixiではいったん対処が取られたようだが、その後、JavaScriptを仕込んだ別のWebサイトを組み合わせて同様の結果をもたらす仕掛けも登場し、対策とのいたちごっこになっている。
「はまちちゃん」の場合、URLをクリックすると書き込まれる日記の本文にさらに「仕掛け」のURLが含まれていたため、被害者は連鎖的に広がった。「連鎖的に広がる」という部分だけを見ればワームに似た現象だが、根本的な原因はWebアプリケーション側の作りにある。
つまりCSRFはmixiに限った問題ではなく、他のサービスやツール、Webアプリケーションでも十分に起こりうることだ。事実、ブログサービスの「はてなダイアリー」でもCSRF問題が確認され、2004年9月に修正されている。
はてなダイアリーの不正な自動操作についての脆弱性について
17:26
先ほど、特殊なURLや外部ウェブページを生成することで、はてなダイアリーの日記編集などの操作を、第三者が日記作者本人に不正に行わせることができる脆弱性を修正しました。
しかも「CSRFによる被害は、攻撃者によって実行させられる機能の重要度に依存し、重要なサイトであればあるほど想定される被害が大きくなる」（中村氏）。今回はたまたま日記の更新という結果にとどまったが、オンラインショッピングサイトなどで悪用されれば、金銭被害や個人情報の流出といった実害が生じるであろうことは容易に想像できる。
対策は「攻撃者による推測を困難にすること」
では、どうすれば問題を防げるのか。根本的な対策は、他のWebアプリケーションの脆弱性同様、サービスやツールを提供する側の対処にかかっている。
中村氏によると、「CSRFの問題点は『機能を実行するためのHTTPリクエストが推測できてしまうこと』」。逆に言えば、攻撃者による推測が困難なパラメータをHTTPリクエストに含めることで解決できるという。
たとえば、予測しにくいセッションIDを用いてきちんとセッション管理を行うことで、CSRFのリスクを減らすことは可能だろう。中村氏によれば「ワンタイムトークンの利用」も有効なほか、「重要な処理を確定させる際に再認証を行う」方法が推奨されるという。つまり、商品購入、決済などの重要な操作を確定させる前に必ずIDとパスワードを入力させることで、CSRFによる攻撃は困難になるという。
なお「HTTP Refererをチェックするという方法も考えられるが、中にはHTTP Refererを出力しないブラウザも存在する」（中村氏）ため、前述した方法が推奨されるということだ。
いずれにしても、どれか1つの方法でCSRFに完全に対処するのは難しい。他のWebアプリケーションの脆弱性と同様、慎重に設計し、実装していくことが重要だろう。
ユーザー側にできることはあるだろうか？ こまめにログイン、ログアウトを行えば、外部URLへのリンクを用いたCSRF攻撃から身を守ることができそうだが、mixiのように内部で仕掛けられる場合は防ぎようがない。
「はまちちゃん」にひっかかってしまった人曰く、怪しいURLに見えたものの「ユーザーどうしの信頼感が比較的高いmixiだからユーザーの個人スペースを使ったトラップにはひっかかりやすいのでは」と述べている。残念ながら、コミュニティの内外を問わず、不審なリンクはクリックしないことに尽きるようだ。
