雨宮かかし

予告.inが突かれたXSS脆弱性とは?

2008-08-07 01:55:58

 どうも、かかしでございます。大したものはございませんが、どうぞよしなに。今回のエントリーでは、『予告.in』を襲ったXSS脆弱性というテーマでお話しましょう。
 

  • 予告.inって何?

 最初に、簡単におさらいを。
 予告.inとは、相次ぐネットでの犯行予告を受けた総務省が、「犯行予告の検知ソフトの開発費を数億円かけて作る!」といい始めたことを受けて、有志の開発者である矢野さとる氏が「0億円、2時間で作った」、犯行予告をピックアップして収集し、犯行予告の情報を投稿・共有できるサイトです。
 そんな予告.inを、XSS攻撃が襲ったと報じられたのは、3日の午後のことでした。

  •  XSSって何?

 さて、ではそのXSSとはどんな攻撃手法でしょうか。
XSSとは、平たく言えば 『Webアプリの入力フィールドを利用してスクリプトを埋め込み、そのサイトが持っている機能であるかのように、悪意あるスクリプトをユーザに実行させる』攻撃手法、あるいはそれを許す脆弱性そのものを言います。サイト外からサイト内へ、サイトを横断して(クロスサイト)スクリプトを仕込むので、Cross site scriptingと呼ばれるわけです。
 具体的には、フォームで入力した内容を確認のためにhtmlとして出力するようなプログラムで、入力フォームにスクリプトを入力されると、適切な対処を行っていない場合には確認ページでスクリプトが起動してしまう、という寸法です。

 スクリプトの内容次第では、強制的に別のページに移動させられたり、入力内容を第三者に送信させられたりするなど、攻撃パターンもいくつかあります。
 URLに入力内容を属性として保持するようなサイトの場合、URLにスクリプトが仕込まれて、ユーザがそれを誤ってクリックすると、そのことがトリガーとなって攻撃対象サイトにスクリプトが埋め込まれてしまう、というパターンもあります。

  • 今回はどんな攻撃があったの?

 では今回の予告.inのケースではどんな攻撃があったのでしょう。

 今回のケースでは、通報フォームのURL欄にiframeが埋め込まれてしまったようです。この仕込をされたフォームでユーザが通報すると、2ちゃんねるに

    タイトル 『警視庁を爆破します』
    本文   『嘘です』
    投稿者 『(投稿者のIP)』

といった内容で新規スレッドが立てられてしまいます。

 iframeを埋め込んで行う、というのは一般的なXSS攻撃のケースとは異なるので、今回の件をXSS攻撃とみなすことを疑問視する方もおられるようです。
しかし、フォームの不備をついて開発者の意図しないコードを埋め込んだ、という点では共通しています。

 それに、リンクを踏ませてスクリプトを発動させるタイプとは違ってサイトそのものの内容が書き換わっているので、今回のケースだとユーザを特殊なリンクを介して攻撃対象サイトにアクセスさせなくてもスクリプトが起動しますし、加えて、ブックマークからアクセスした場合でも、同じくスクリプトが起動してしまいます。そういった意味で、いわゆる一般的なケースより用心しにくい厄介な攻撃になっていたといえるでしょう。

  • 2ちゃんねるに落度はなかったの?

 もう一つ特筆すべき特徴があります。それは攻撃のプロセスに2ちゃんねるのフォームが絡んでいる点です。この点については、2ちゃんねる側にCSRFに似た脆弱性が(昔から)あることを指摘されている方もおり、今回もそれを悪用された形になります。

 CSRFとはCross Site Request Forgeryの略称。 Forgeryとは偽造を意味します。Cookieなどでアクセス制御をしているサイトで、ログイン状態のユーザが送信するリクエストに偽装した攻撃スクリプトを紛れ込ませることで、非ログイン状態にして目的のスクリプトを攻撃対象サイトで起動させる攻撃手法です。XSSと似ていますね。
 今回のケースでは、2ちゃんねるは特にログインチェックなどでアクセス制御をしているわけではありませんから、厳密に言えばその点がCSRFとは違います。

 一般的にこの脆弱性をカバーするためには、リファラ(リンク元)を確認し、それが正常なURLでなければ送信を受け付けない、というのが一つの方法です。
 2ちゃんねるの場合は、リファラが2chドメインであることを確認している、という話もありました。しかし今回は上手くリクエストを操作してこの対策を貫通させられたのか、あるいはこの対策がなされているという話がデマなのか、ともかく、攻撃者の狙い通り、スクリプト(?)が実行されてしまいました。

  • 今回の事件を受けて

 今回お話したような脆弱性は、そこかしこで見つけることができます。言ってみればフォームの数だけ脆弱性が生まれる可能性があるわけですから。
 ですが、よくある脆弱性については既に起こった事件から学んで、パターン対応することには意味があります。

XSSに対する対策では < や>を別の文字に置き換えてしまうこと。つまり

・HTMLエンティティに置き換える

という方針で対策を立てることが基本になります。ただ、それだけでは不十分で、

・エンコード指定をしっかり書き込む (たとえば UTF-7の場合「<」を「+ADw-」など、別の文字に見せかけることができてしまうので)

など、変則的なスクリプトの入力についても耐える仕様になっている必要があります。

 そのほか、JavaScriptのコードをサーバサイドで生成している場合や、入力値をタグの属性値として使用しているような場合には注意が必要であること。また、基本的なことですが、タグの属性値は必ずダブルクォートで括る、なども、すぐに気をつけられる重要なポイントです。

 ウェブが一般に普及してくるにつれて、入力フォームなども大量に作られています。これは、XSSで攻撃できる可能性のある急所が増えた、ということでもあります。この手の脆弱性の除去には、開発者の丁寧な対応が求められる部分です。改めて、気を引き締めてコトにあたりたいものですね。

それではまた!

※このエントリは ブロガーにより投稿されたものです。朝日インタラクティブ および ZDNet Japan編集部の見解・意向を示すものではありません。
  • 新着記事
  • 特集
  • ブログ