Copyright © 2000-2005 eazyfox. All Rights Reserved.
HOME| Firewall | Security| 製品紹介| SecuTool| Forest| Hello| Link| 掲示板| 雑談掲示板| SiteMap| Contact

Webを参照するときに、決まったコンテンツ(静的コンテンツ)を表示するだけではただの電子図書館になってしまう。クライアント(参照するPC)で何かプログラムを実行することで、インタラクティブな動的コンテンツを表示するとインターネットの利用方法が格段に広がるのである。簡単な例ではブラウザ上でネットゲームを実現しようとすれば、ブラウザの上でゲームプログラムを実行し、他者の位置や姿勢の情報だけをWebサーバから取得してブラウザにゲーム画面を表示すればよい。

乱暴な言い方だが、この機能を実現するための仕組みがJAVAでありActiveXである。つまりクライアントPCで実行可能なモジュールをWebサーバからDownloadすることで、ブラウザ上でプログラムを実行し、その結果をサーバに送って処理を行うというものだ。

このように考えてみるとJAVAにしてもActiveXにしてもセキュリティが確保されていないと、悪意のあるプログラマが作成したJAVAアプレット(InternetからDownloadして使用するものをアプレットといい、PCのDiskに保存してから実行するものをローカルコード・アプリケーションと呼ぶ）が無条件にクライアントで実行されるとなると、そのプログラマの好き放題が可能ということになる。

・セキュリティの確保

まずJAVAのセキュリティの確保方法だが

上の表で左から2番目の列にあるJDKx.xはJAVAの開発環境を表している。
ActiveXはJDK1.1以降と同じようにセキュリティを電子署名で行っている。動作も同じで信用できないActiveXはサンドボックス上で動作する。また信用できるActiveXには制限がない。
よくMicrosoftの追加モジュールをインストールしようとすると「このプログラムは署名されています」というダイアログが出てきて「信頼しますか？」でYESをクリックするとインストーラが実行する。これから判るように信用するコードはDiskへのアクセスやプログラムのインストールといった本来インターネット上の制限を越えた動作が可能となる。

サンドボックスをもう少し簡単にいうとDiskレスの仮想のPCをメモリ上に持つようなもので、アプレットをこの仮想PC上で動かしてもDiskにはアクセスできない。
このようにJAVAの進化と共にセキュリティが多様な要求にこたえられるように変更されている。しかし決してセキュリティのレベルが強化されているわけではない。区別する方法が変わってきているだけだ。
つまりJAVAの進歩が安全性の向上となっているわけではない。あくまでも制限(セキュリティポリシー)を設定できるようになっているだけだと判断するのが正しい。

実際の動きをみてみるとサンドボックスで動くアプレットでも動作するためのワーク領域とも言うべきファイルは読み書きできる。例えば共通サブモジュールをアプレットと同時にダウンロードして使用するようなとき、共通サブモジュールはDiskに一時保存される。このようにある程度のDiskを利用できないとアプレットがしょぼい機能しかもてないとか、アプレットに共通サブモジュールの記述も全部含めてないといけないような不便なものになるからだ。

そこである指定したフォルダは読み書きできる権限が与えられている。しかしサンドボックスやセキュリティポリシーによって他の領域を読むことは制限されているので悪い影響が出ることはない。サンドボックスなどの持つセキュリティ制限、またはセキュリティポリシーがJAVAやActiveXを動作させるシステムで厳格に守られていれば破壊を目的とするような危険なアプレットであっても実際にはワーク領域にしかアクセスできないので被害が発生することはないのだ。

では、JAVAやActiveXが危険なのはなぜか？

・サンドボックスやセキュリティポリシーに穴がある

サンドボックスに穴があるとどうなるか？先程あるフォルダは読み書きできると書いたが、そのフォルダが"C:\"というフォルダだったらどうなるだろう？答えはCドライブ全てにアクセス可能となる。
信用できないアプレットと指定してサンドボックスでの制限された動作を期待してもCドライブの中身を自由に読み書きできてしまうことになる。

このようなJAVAの実行環境（JAVA Vurtial Machine：JAVA VM）が実際にMicrosoftからリリースされていた。WindowsはDosの時代からカレントディレクトリ(自分が実行しているフォルダ位置)はデフォルトでアクセスが可能となる仕様になっている。これは動作しているプログラムと同じフォルダにあるDLLやデータを読む必要があるからだ。

しかしサンドボックス上で動くアプレットがVM自身のカレントフォルダまで読めてしまったのでは問題だ。VMのバージョンやOSによってこのカレント位置は異なるが、サンドボックスに大きな穴があいていることは確かだ。現在この問題を解消したVMがリリースされているのでアップデートは必ず行って欲しい。
またこれ以外にもたくさんのVMに関するたくさんの問題が発覚している。ほとんどがアクセスしてはいけない領域まで読み書きができてしまうという現象だ。

VM のファイルの読み取り」の脆弱性に対する対策 (MS00-081)
「Microsoft VM による ActiveX コンポーネントの制御」 の脆弱性に対する対策 (MS00-075)
「VM ファイル参照 問題」の脆弱性に対する対策 (MS00-011)
「Java VM アプレット」の脆弱性に対する対策 (MS00-059)
「仮想マシン ベリファイア」の脆弱性に対する対策 (MS99-045)
「仮想マシン サンドボックス」の脆弱性に対する対策 (MS99-031)
最新のVM（2001/6現在)はhttp://www.microsoft.com/japan/java/vm/dl_vm40.aspを参照してアップデートできる。

・電子署名が偽者

電子署名は暗号化された署名で偽造することはできないものであり、ダウンロード時にアプレットの製作者として表示されるものだが、この電子署名が不正取得されたり、有効期限がすでに切れているといった怪しいものが存在する。
これに対応するには無効になった電子署名の一覧を認証サイトから取ってくることで見分けなければならない。

実話として以前認証会社にMicrosoftの社員を名乗る人が電話で電子署名のコードの発行を依頼してきた。直ぐにコードは発行されたが、あとで確認したところ電話をしてきた人はMicrosoftとは関係なく、名前を騙っただけということが判明した。つまりこの電話を掛けた人は正式なMicorsoftの電子署名コードを持っているのである。

あなたがどこかのサイトで「このアプレットはMicrosoft社製です」と表示されると「何か新しいプラグインがこのサイトを見るのに必要で、Microsoftのプラグインならインストールしても安心だ！」と思うのではないだろうか。そしてインストールが終了したときにはトロイの木馬がしっかり動いていることになりかねない。

・スクリプト

JAVAアプレットやActiveXコントロールをクライアントのブラウザ上で実行するためにはスクリプト言語(JavaScriptやVBScriptなど)による手続きが用いられる。スクリプトはHTML内に記述する簡単な手続き言語で、新しいWindowを開いたり、文字や絵の表示をコントロールしたりといった簡単な動きをもったWebページを構成するためのものである。
簡単なスクリプトだけではブラウザ上でこれまでのWindowsアプリケーション並みの動きをもったでアプリケーションは作ることができない。

そこでスクリプトからアプレットやActiveXを呼び出してより見易い、使いやすいブラウザ上で動くアプリケーションが実現できるのだ。スクリプトをブラウザ上で実行できないように設定すると多くのサイトでメニューが出なくなったり、画面が動かなくなったりする。そしてつまらない絵と文字だけの(筆者のサイトはつまらないと自覚している)サイトしかみることができないので、切ってしまうのが良いとは考えていない。

通常のサイトはスクリプトは無効にするが、信頼できるサイトで且つスクリプトが実行できないと正しいページが表示できないようなサイトだけスクリプトを有効にするのがよい

IEであれば「インターネットゾーン」ではスクリプトは無効にしておいて、信頼できるサイトだけ「信頼済みサイト」へ登録するような使い方が望ましい

SecurityのTOPに戻る