初めに
僕ははまちちゃんではありません。
つい最近はまちちゃん事件について知りました。
Webアプリケーションエンジニアの端くれとして面白みを感じたのでまとめていきます。
はまちちゃん事件とは
「はまちちゃん事件」とは、2005年に大手SNS「mixi」で発生した現象で、Webアプリケーションのセキュリティ問題の一種であるクロスサイトリクエストフォージェリ（CSRF）攻撃によって起きた事案です。
この事件では、多数のユーザーが自分の意図せず「ぼくはまちちゃん！」というタイトルの日記を公開してしまうという事態が発生しました。
事件の詳細については、以下のような流れで発生しました。
- あるユーザーが「こんにちはこんにちは!!」という言葉と特定のURLを含む日記を投稿します。
- このURLをクリックしたユーザーの日記にも、自動的に「ぼくはまちちゃん！」という新しい日記が書き込まれ、さらにその日記にも同じURLが含まれていました。
- このようにして、URLをクリックしたユーザーが次々と同様の投稿をすることにより、被害が連鎖的に広がりました。
はまちちゃん事件の影響
この事件は、Webアプリケーションのセキュリティ対策の重要性を一般に広く知らしめるきっかけとなりました。
また、模倣犯によるCSRFの脆弱性を利用したイタズラが横行するなど、Webセキュリティの認識を高める上で重要な役割を果たしました。
はまちちゃん事件を通じて、Webサイトやアプリケーションの開発者はユーザーのセキュリティを保護するために、CSRF対策の強化が必要であるということを再認識したのです。
CSRF攻撃について
CSRF攻撃（クロスサイトリクエストフォージェリ攻撃）とは、ウェブアプリケーションの脆弱性を悪用する攻撃方法の一つです。
この攻撃は、ユーザーが意図しない行動をウェブサイトに対して行わせることを目的としています。
例えば、ユーザーがログインしているウェブサービス上で、攻撃者が仕掛けた悪意のある操作（例えば、設定の変更、メッセージの送信、金銭の送金など）をユーザーに無意識のうちに実行させます。
CSRF攻撃の実施方法は以下の通りです。
- 認証済みのユーザーがブラウザを通じてウェブアプリケーションにアクセスします。
この時、ユーザーのブラウザはセッションIDなどの認証情報を含むクッキーを保持しています。 - 攻撃者はユーザーを欺いて、悪意のあるリクエストをウェブアプリケーションに送信させます。
これは、フィッシングメールによるリンククリックや、攻撃者がコントロールするウェブページ上の隠されたフォームを自動的に送信させることで実現されることがあります。 - ユーザーのブラウザは、悪意のあるリクエストとともに、認証情報を含むクッキーも自動的にウェブアプリケーションに送信します。
- ウェブアプリケーションは、リクエストが正規のユーザーから送られたと認識し、リクエストされた悪意のある操作を実行します。
その他の例については以下が挙げられます。
- オンラインバンキングの送金操作
攻撃者が作成したウェブページに訪問したユーザーが、知らないうちにオンラインバンキングで第三者への送金を行う。
この攻撃では、ユーザーが既にバンキングサイトにログインしている状態で、攻撃者が用意した送金リクエストを実行させる。 - アカウント情報の変更
攻撃者が作成したページを介して、ユーザーが使用しているサービスのアカウント情報（例えば、メールアドレスやパスワード）を無意識のうちに変更させる。 - 商品の購入
オンラインショッピングサイトにログイン中のユーザーが攻撃者のページを訪問することで、ユーザーに知らせることなく商品を購入させ、配送先を攻撃者が指定した住所に設定させる。 - フォーラムやコメント欄での不正投稿
ユーザーがフォーラムやニュースサイトのコメント欄にログインしている状態で、攻撃者の仕掛けたスクリプトにより、スパムや誹謗中傷などの不適切なコメントを投稿させる。
CSRF攻撃の対策
CSRF攻撃の解決方法としてIPAから以下の4つが提示されています。
- 処理を実行するページをPOSTメソッドでアクセスするようにし、その「hiddenパラメータ」に秘密情報が挿入されるよう、前のページを自動生成して、実行ページではその値が正しい場合のみ処理を実行する。
ここでは具体的な例として、「入力画面 → 確認画面 → 登録処理」のようなページ遷移を取り上げて説明します。
まず、利用者の入力内容を確認画面として出力する際、合わせて秘密情報を「hidden パラメータ」に出力するようにします。
この秘密情報は、セッション管理に使用しているセッションIDを用いる方法の他、セッションIDとは別のもうひとつのID（第2セッションID）をログイン時に生成して用いる方法等が考えられます。
生成するIDは暗号論的擬似乱数生成器を用いて、第三者に予測困難なように生成する必要があります。
次に確認画面から登録処理のリクエストを受けた際は、リクエスト内容に含まれる「hiddenパラメータ」の値と、秘密情報とを比較し、一致しない場合は登録処理を行わないようにします。
このような実装であれば、攻撃者が「hiddenパラメータ」に出力された秘密情報を入手できなければ、攻撃は成立しません。
- 処理を実行する直前のページで再度パスワードの入力を求め、実行ページでは、再度入力されたパスワードが正しい場合のみ処理を実行する。
処理の実行前にパスワード認証を行うことにより、CSRFの脆弱性を解消できます。
ただし、この方法は画面設計の仕様変更を要する対策であるため、画面設計の仕様変更をせず、実装の変更だけで対策をする必要がある場合には、上記または下記の対策を検討してください。
この対策方法は、上記と比べて実装が簡単となる場合があります。
たとえば、セッション管理の仕組みを使用しないでBasic認証を用いている場合、上記の対策をするには新たに秘密情報を作る必要があります。
このとき、暗号論的擬似乱数生成器を簡単には用意できないならば、この対策の方が採用しやすいと言えます。
- Refererが正しいリンク元かを確認し、正しい場合のみ処理を実行する。
Refererを確認することにより、本来の画面遷移を経ているかどうかを判断できます。
Refererが確認できない場合は、処理を実行しないようにします。
またRefererが空の場合も、処理を実行しないようにします。
これは、Refererを空にしてページを遷移する方法が存在し、攻撃者がその方法を利用して CSRF 攻撃を行う可能性があるためです。
ただし、ウェブサイトによっては、攻撃者がそのウェブサイト上に罠を設置することができる場合があり、このようなサイトでは、この対策法が有効に機能しない場合があります。
また、この対策法を採用すると、ブラウザやパーソナルファイアウォール等の設定でRefererを送信しないようにしている利用者が、そのサイトを利用できなくなる不都合が生じる可能性があります。
本対策の採用には、これらの点にも注意してください。
- 重要な操作を行った際に、その旨を登録済みのメールアドレスに自動送信する。
メールの通知は事後処理であるため、CSRF 攻撃を防ぐことはできません。
しかしながら、実際に攻撃があった場合に、利用者が異変に気付くきっかけを作ることができます。
なお、メール本文には、プライバシーに関わる重要な情報を入れない等の注意が必要です。
以上の対策により、CSRF攻撃に対する安全性の向上が期待できます。
まとめ
はまちちゃん事件を私はつい最近まで知りませんでした。
はまちちゃん事件はネタで終了していますが、様々なことがネット上でできるようになった現代においては、多くの犯罪に利用される重大な脆弱性となっているでしょう。
ITと脆弱性は隣り合わせであることを意識し、常に気を張っていきましょう。
参考