セキュリティが強化されたWindows Vistaの登場により,ボット問題は沈静化に向かうだろう。その一方で,JavaScriptを使ったWebブラウザへの攻撃が急増している。「業務のすべてをWebブラウザで提供する」という流れの中で,大きな脅威になりそうだ。

JavaScript攻撃の狙いはボットと同じ

 攻撃者がJavaScriptで狙うのはボット同様,金銭にかかわる情報である。最も価値があるのは,クレジットカード番号と,銀行サイトへのアクセス権をもたらすIDとパスワードである。これらの機密情報を盗むために,Webメールや社員向けWebサーバーがターゲットとなる。

 情報を盗むために使われる典型的な手法として,クッキーの横取りがある。その手法とは,Webブラウザに「横取り用のJavaScript」を送り込むというもの。具体的には,(1)クッキーを読み出す,(2)このクッキーを攻撃者の管理下にあるサイトに送信する──という振る舞いを実行するJavaScriptを使ってクッキーを盗み出す。そして,このクッキーを犯罪者のWebブラウザにセットしてWebサイトにアクセスすれば,そのクッキーを持っていたユーザーになりすましてアクセスできる。これ以外にも,ユーザーがWebブラウザに入力した文字をJavaScriptで読み取り,ユーザー名/パスワードを盗み出すという手口もある。

 ただし,攻撃者がこうした攻撃を成功させるためには越えなければならないセキュリティ上の壁がある。それは,Webブラウザが備える「クロスドメインの制限」と呼ばれるセキュリティ機構だ。

 簡単に説明しよう。例えば,Webブラウザでウインドウを二つ立ち上げ,一つはドメインAにある銀行のページを,もう一つはドメインBにある悪意あるJavaScriptが含まれているWebページを開いたとする。このとき,ドメインBのページで動作しているJavaScriptを使ってドメインAのページのデータを操作することはできない。これが「クロスドメインの制限」である。ただし,両方が同じドメインなら別のウインドウで動いているJavaScriptを使って,相互にデータを操作できる。

クロスドメインは軽々と越せる

 実は,この制限を越えるのはそれほど難しくない。多くのWebサイトにクロスサイト・スクリプティング(cross site scripting,XSSと表記することもある)のぜい弱性があるためだ。専門家は7~8割のWebサイトにこのぜい弱性があるという。実際,米グーグルや米ヤフーなど厳密な開発を行っているはずの著名なサイトでも,クロスサイト・スクリプティングのぜい弱性がいくつも報告されている。

 クロスサイト・スクリプティングとは,Webサーバーに送るデータの中にJavaScriptを入れて送ったときに,そのJavaScriptが返信のHTMLページに含まれた状態で戻ってくると,それがユーザーのWebブラウザで実行されてしまうという現象を指す(図1)。クロスサイト・スクリプティングのぜい弱性があるWebサーバーが存在すると,メール本文中のリンク,掲示板やWebページのリンクをたどることで攻撃を受けてしまう危険性が生じる。

図1●クロスサイト・スクリプティングのぜい弱性を狙った攻撃
図1●クロスサイト・スクリプティングのぜい弱性を狙った攻撃  [画像のクリックで拡大表示]

 例えば,Webブラウザからのリクエストに名前を入れて送ると,その名前が入ったHTMLを返す「welcome.asp」というWebアプリケーションがあったとする。このアプリケーションは「http://fumidai-site/welcome.asp?user=山田」のように「user=山田」というパラメータを与えてリクエストを送ると,「山田さんこんにちは!」というページが表示されるものだ。

 このWebアプリケーションがクロスサイト・スクリプティング対策を施していない場合,「山田」のところにJavaScriptのコードを付加して送るとJavaScriptが埋め込まれたまま返って来る。もし,このコードが悪意あるプログラムであったとしても,Webブラウザはこれを解釈して実行してしまう。

ローカル・アプリが穴になる

 Webサイト側にぜい弱性がなくても,ローカル側に存在するぜい弱性が原因でクロスサイト・スクリプティングが成功するケースもある。Webブラウザと連携して動作するアプリケーションにぜい弱性がある場合だ。

 例えば,米アドビのFlashやAcrobat Reader,米アップルのQuickTimeには,ファイルの中に書き込まれているJavaScriptを実行する機能がある。これらのアプリケーションにぜい弱性があり,外部から任意のJavaScriptが入力できるようになっていると,同様の攻撃ができてしまうのである。

 具体例を示そう。写真1はAcrobat Reader 7.0.8以前のバージョンに存在したクロスサイト・スクリプティングのぜい弱性を使って攻撃した例である。Webサイトにある普通のPDFファイルの後ろに「#JS=javascript:alert("Danger")」という具合にJavaScriptを追加するだけで,そのスクリプトが実行されてしまう。このときにJavaScriptが実行されるドメインはPDFファイルが置かれているサイトになる。

写真1●PDFに発見されたクロスサイト・スクリプティングのぜい弱性
写真1●PDFに発見されたクロスサイト・スクリプティングのぜい弱性
[画像のクリックで拡大表示]

 写真1では,日経コミュニケーションのサイト上にあるPDFファイルを使って実行したところを示しているが,PDFファイルが公開されているWebサイトならどこでも仕掛けることが可能である。銀行や証券会社などがWebサイト上で公開しているPDFファイルを使っても同様の攻撃ができてしまう。

 似たようなぜい弱性は過去にFlashでも報告されている。他のアプリケーションでも今後,ぜい弱性が見付かる可能性がある。

JavaScriptでポート・スキャンを実行できる

 JavaScriptは,ここまで述べたような直接的な情報盗難だけではなく,企業の社内ネットワーク攻撃のための下調べやきっかけ作りにも使える。具体的には,クロスサイト・スクリプティングを使ってターゲットとなるユーザーのWebブラウザにJavaScriptを送り込んで,LAN内に設置されているWebサーバーに割り当てられているIPアドレスやポートを調べたり,サーバー/ネットワーク機器の設定変更を実行したりできる(写真2)。

写真2●JavaScriptで作られたポートスキャン・ツール
写真2●JavaScriptで作られたポートスキャン・ツール
http://www.gnucitizen.com/上にあるツールを実行したところ。IPアドレスとポート番号を指定して「scan」ボタンを押すと,ポート・スキャンができる。

 WebサーバーのIPアドレスは,JavaScriptを使ってIPアドレスの総当たりでアクセスすれば見付けられる。例えば,192.168.0.1~192.168.255.254の範囲でアドレスを順番に変えてアクセスを試みて,反応があった場合にWebサーバーが動いていると判断するわけだ。こうしたプログラムは「ポート・スキャン」と呼ばれており,ぜい弱性をチェックする用途などで使われているが,それとほぼ同じ機能をJavaScriptで実現できるのだ。

 Webサーバー・プログラムの種類はそのサーバー上に固有のファイルがあるかどうかでチェックできる。例えば,Apacheはデフォルトの状態で「/icons」というディレクトリに「apache_pb.gif」というファイルが存在するので,これがあるかどうかを調べることで推定できる。他のWebサーバーやグループウエア,プリンタ,ルーターなどでもベンダーごとに固有のファイルが存在するため特定が可能だ。

 一方の設定変更は,Webブラウザの設定画面が用意されているサーバーやネットワーク機器が対象になる。パスワードがデフォルトのまま運用されていたり,推測可能なものだと,JavaScriptを使ってアクセスし,設定を変更できてしまう。特にルーターやファイアウォールの場合,外部からの通信を受け入れるように設定されてしまうと,社内LANが外部の攻撃にさらされる危険がある。

Webブラウザがハイジャックされる

 攻撃者が社内LANを攻めるには,踏み台にしているユーザーのWebブラウザとターゲットのWebサーバーの通信をモニターしながら,対話的に攻撃する必要がある。これを実現する手法として,「Webブラウザ・ハイジャック」とでも呼ぶべき手法がすでに考案されている。Webブラウザ・ハイジャックの特徴は「インライン・フレーム」という機能を使うところにある。インライン・フレームはWebページの任意の場所に,別のURLから読み込んだWebページを表示する機能である(図2)。

図2●インライン・フレームの例
図2●インライン・フレームの例  [画像のクリックで拡大表示]

 Webブラウザ・ハイジャックでは,クロスサイト・スクリプティングを使って,Webブラウザの画面いっぱいにインライン・フレームを表示し,大元のページがユーザーに見えないようにする。大元のページのHTMLにはJavaScriptが埋め込まれており,これがLANの調査などをするわけだ。タイマーを仕込んでおき,短い時間で攻撃者の管理下にあるWebサイトからJavaScriptを読み込むようにすれば,犯罪者とユーザーのWebブラウザの間で対話をしながら攻撃することができてしまう。

 インライン・フレームにすることで,ユーザーがWebページでリンクをたどって,別のページを表示したとしてもずっとWebブラウザと攻撃者の間のパイプを途切れないようにしておける。大元のWebページはWebブラウザに読み込まれたままなので,そこに埋め込まれたJavaScriptも残ったままになるからだ。

 ちなみに,大元のWebページとインライン・フレーム内に表示されたWebページの間も先に述べたクロスドメインの制限が適用される。大元のWebページとインライン・フレーム内のWebページが同じドメインならJavaScriptを使って相互にデータを読み取ったり,文字列を操作したりできてしまう(図3)。Webブラウザ・ハイジャックはユーザーの監視に使われる危険性もあるのだ。

図3●インライン・フレームの動作モデル
図3●インライン・フレームの動作モデル  [画像のクリックで拡大表示]

出典:日経コミュニケーション 2007年5月1日号 100ページより
記事は執筆時の情報に基づいており、現在では異なる場合があります。