このトピックでは、JavaScriptコードからアプレットへの呼出しを含む、セキュリティ・サンドボックスに制限されるコードを持つ権限を必要とする混合コードを処理する方法について説明します。
セキュリティ・サンドボックスに制限されているコンポーネントを含む特権付きのJava Web Startアプリケーションおよびアプレットは、混合コードがアプリケーション・ベンダーによって意図されたものでないかぎり、安全でない可能性があります。プログラムに特権付きコンポーネントとサンドボックス・コンポーネントの両方が含まれている場合は、セキュリティ警告が表示されます。JavaScriptコードはサンドボックスに制限されているため、同様にセキュリティ警告が表示される可能性があることに注意してください。JavaScriptコードを認証するためのマニフェスト属性の詳細は、26.5項「Caller-Allowable-Codebase属性」を参照してください。
セキュリティ警告によれば、Javaがセキュリティ問題の発生が考えられるアプリケーション・コンポーネントを検出したため、アプリケーション・ベンダーに問い合わせて、それらのアプリケーション・コンポーネントが改変されていないことを確認するよう勧めています。
このダイアログでは、それらのアプリケーション・コンポーネントの実行を「ブロック」するか、または「ブロックしない」ことを選択します。オプションの「詳細情報」リンクをクリックすることもできます。
「ブロック」ボタンをクリックすると、安全でない可能性のあるコンポーネントの実行がブロックされるので、プログラムが終了する可能性があります。「ブロックしない」ボタンをクリックすると、いくつかの追加保護の下でアプリケーションまたはアプレットの実行が継続されます。
警告を表示するのがデフォルトの動作ですが、この状況の処理方法を管理するためのオプションが存在します。
ユーザーやシステム管理者は、さまざまな保護オプションを使用できます。詳細は、27.1項「ユーザー向けの混合コード保護オプション」を参照してください。
開発者とデプロイヤは、2つのマニフェスト属性を使用できます。詳細は、27.2項「混合コードの警告なしの特権付きのアプリケーションおよびアプレットのセキュアなデプロイ」を参照してください。
注意: マニフェスト・ファイルを変更する方法、JARファイルに署名する方法、配備構成ファイルを使用する方法など、よくわからない概念がある場合は、27.4項「詳細情報」を参照して有用なリンクにアクセスしてください。 |
混合コード・プログラムの処理方法を管理するためのメカニズムが2つ用意されています。
Javaコントロール・パネルから
混合コード・プログラムの処理方法を管理するには、Javaコントロール・パネルを使用します。4レベルの制御が可能です。
Javaコントロール・パネルへのアクセス方法はプラットフォームごとに異なるほか、同一プラットフォームのリリースごとに異なる場合もあります。Microsoft Windowsでそのパネルを表示するには、「スタート」メニュー>「コントロール・パネル」>「Java」
の順に選択します。
「詳細」タブの「混合コード」セクションでは、最初の3つのオプションはどれもソフトウェア保護を有効にしますが、動作が少しずつ異なります。
有効 - 必要であれば警告を表示する これはデフォルトの設定です。潜在的なセキュリティ・リスクが検出されると、警告ダイアログが表示されます。「ブロック」をクリックすると、安全でない可能性のあるコンポーネントの実行がブロックされるので、プログラムが終了する可能性があります。「ブロックしない」をクリックすると、いくつかの追加保護の下でアプリケーションまたはアプレットの実行が継続されます(名前は同じでもアクセス権のレベルが異なるパッケージやリソースがあとで検出されても、それらはロードされません)。
有効 - 警告を表示せずに、保護をかけて実行する このオプションは警告ダイアログを抑制します。コードは、ユーザーが警告ダイアログで「ブロックしない」をクリックしたかのように実行されます。
有効 - 警告は表示しないが、信頼できないコードは実行しない このオプションは、警告ダイアログを抑止し、ユーザーが警告ダイアログで「ブロック」をクリックしたかのように動作します。
最後のオプション「検証を無効にする」はお薦めできません。このオプションを指定すると、特権付きコードとサンドボックスコードが混在するものを一切チェックしなくなります。ユーザーは、安全でない可能性のあるコードを、警告も追加の保護も一切なしで実行することになります。
deployment.properties
ファイルから
第21章「配備構成ファイルおよびプロパティ」
で説明されているように、混合コード保護オプションは、deployment.security.mixcode配備プロパティを使用して設定することもできます。
deployment.security.mixcode=ENABLE
このオプションは、混合コードの検証を有効にします。潜在的なセキュリティ・リスクが検出されると、警告ダイアログが表示されます。これが、このプロパティのデフォルト値です。
deployment.security.mixcode=HIDE_RUN
このオプションは警告ダイアログを抑制します。コードは、ユーザーが警告ダイアログで「ブロックしない」をクリックしたかのように実行されます。
deployment.security.mixcode=HIDE_CANCEL
このオプションは、警告ダイアログを抑止し、ユーザーが警告ダイアログで「ブロック」をクリックしたかのように動作します。
deployment.security.mixcode=DISABLE
このオプションはお薦めできません。特権付きコードとサンドボックスコードが混在するものをソフトウェアで一切チェックしなくなります。ユーザーは、安全でない可能性のあるコードを、警告も追加の保護も一切なしで実行することになります。
この項では、開発者とデプロイヤ向けに、信頼できるコンポーネントを信頼できないコンポーネントで置き換えることによって、Java Web Startアプリケーションとアプレットが悪用されることを防止するためのベスト・プラクティスについて説明します。
Java SE 6 Update 19以降、特権付きのJava Web Startアプリケーションとアプレットをデプロイするための2つのJARマニフェスト属性が使用可能になりました。これらのマニフェスト属性のいずれかを含めた場合、警告ダイアログは表示されません。
開発者とデプロイヤは、自身のJava Web Startアプリケーションとアプレットをチェックし、特権付きコードと信頼できないコードが混在しているか確認すべきです。それらのアプリケーションとアプレットのユーザーが、それらのアプリケーションとアプレットを間違って悪意のあるWebサイトからダウンロードする可能性がある場合には、次のいずれかの属性を指定して配備または再配備することを検討すべきです。既存の署名付きJARにこれらのマニフェスト属性を追加したあと、JARに署名し直す必要があります。マニフェスト・エントリを指定したときの再署名には、クラスのソース・コードおよびリソースは不要です。
Trusted-Only
属性信頼できないコンポーネントを必要としないアプリケーションとアプレットでは、Trusted-Only
属性を使用します。警告ダイアログは表示されず、この属性を含むJARファイルをロードするアプリケーションまたはアプレットは、信頼できないクラスやリソースを一切ロードしません。この属性は、特権付きのアプリケーションまたはアプレットが転用されて、信頼できないコンポーネントが追加されることを防止します。詳細は、26.7項「Trusted-Only属性」を参照してください。
Trusted-Library
属性信頼できないコンポーネントを許可するように設計されているアプリケーションとアプレットでは、Trusted-Library
属性を使用します。警告ダイアログは表示されず、アプリケーションまたはアプレットは、信頼できないクラスやリソースを含むJARファイルをロードできます。この属性は、特権付きのアプリケーションまたはアプレット内のコンポーネントが転用されて、信頼できないコンポーネントが追加されることを防止します。この属性の使用の詳細は、26.8項「Trusted-Library属性」を参照してください。
Trusted-Library
属性は、特権付きJavaコードとサンドボックスJavaコード間の呼出しに使用されます。Javaコードを呼び出すJavaScriptコードが含まれている場合は、26.5項「Caller-Allowable-Codebase属性」を使用します。
アプリケーションの開発やデプロイを担当しています。この問題の心配をする必要があるかどうかは、どのようにしてわかりますか。
回答: 27.2項「混合コードの警告なしの特権付きのアプリケーションおよびアプレットのセキュアなデプロイ」で説明されているマニフェスト属性を使用せず、特権付きのJava Web Startアプリケーションまたはアプレットを実行したときに警告ダイアログが表示された場合、プログラムに混合コードが含まれており、影響があることになります。
影響があるかどうかを判別するために実行可能なテストはありますか。
回答: 最新バージョンのJREを使用して、アプレットおよびJava Web Startアプリケーションをテストします。警告ダイアログが表示された場合、そのアプリケーションには混合コードが含まれています。
どのようなアクションを取ることができますか。
回答: エンド・ユーザーは、警告ダイアログへの応答で「ブロック」または「ブロックしない」のどちらをクリックするかを決定する前に、「詳細情報」リンクをクリックできます。IT管理者またはシステム管理者であれば、前述の対応する配備プロパティを使って、混合コード保護オプションのいずれかを選択し、企業内のデスクトップを構成できます。開発者およびデプロイヤであれば、改ざんを防止するためにマニフェスト・エントリを使ってアプリケーションを保護できます。これらのマニフェスト・エントリのいずれかを使用した場合、警告ダイアログは表示されません。
JavaのISV、OEM、およびアプリケーション・ベンダーは自身のコードに対して何をする必要がありますか。
回答: 27.2項「混合コードの警告なしの特権付きのアプリケーションおよびアプレットのセキュアなデプロイ」で説明されている2つのマニフェスト属性は、アプリケーション・ベンダーによるJava Web StartアプリケーションおよびJavaアプレットのデプロイまたは再デプロイに使用できます。
インターネットからのJavaアプレットおよびJava Web Startアプリケーションについてはどうですか。それらについて心配する必要がありますか。
回答: Java Web StartアプリケーションやJavaアプレットに混合コードが含まれていれば、それがインターネット、イントラネットのどちらからダウンロードされたものであっても、ユーザーに警告ダイアログが表示されます。
企業のファイアウォールの内側にいる場合はどうですか。
回答: 混合コードの問題が適用されます。質問「インターネットからのJavaアプレットおよびJava Web Startアプリケーションについてはどうですか。それらについて心配する必要がありますか。」を参照してください。
これはOracle JRockitの問題ですか。
回答: いいえ。
別のベンダーのJavaの実装を使用しています。これらも同じように影響がありますか。
回答: ベンダーに問い合せて、そのベンダーの実装に関する助言を得てください。
開発者です。この拡張機能で追加されたセキュリティ例外は、どのようなものですか。
回答: 次のSecurityException
メッセージは、情報およびデバッグのためだけに記述されています。実際のメッセージの内容は、実装やリリースによって変わる可能性があります。
これらのSecurityException
がスローされるのは、JARファイルにマニフェスト属性のいずれかが含まれ、そのJARファイル自体に信頼できないコンポーネントが含まれていた場合です。
attempted to open sandboxed jar "+ url +" as Trusted-Only attempted to open sandboxed jar "+ url +" as Trusted-Library
次のSecurityException
がスローされるのは、JARファイルにTrusted-Only
マニフェスト属性が含まれ、信頼できないコンポーネントへのアクセスが以前に行われていた場合です。
attempted to open Trusted-Only jar "+ url +" on sandboxed loader
次のSecurityException
がスローされるのは、Trusted-Only
マニフェスト属性を含むJARが少なくとも1つ開かれ、そのあとで信頼できないコンポーネントをロードすることが試みられた場合です。
Trusted-Only loader attempted to load sandboxed resource from "+ url"
次の2つのSecurityException
がスローされるのは、まず混合コンポーネントが検出され、混合を許可しないことが決定された場合です。最初の場合は、以前にロードされたものがすべて信頼できるもので、そのあと、信頼できないコンポーネントをロードすることが試みられました。2番目の場合はその逆の条件です。
trusted loader attempted to load sandboxed resource from "+ url" sandboxed loader attempted to load trusted resource from "+ url"
次の2つのSecurityException
がスローされるのは、以前に混合コンポーネントが検出されていて、それらの共存を許可することが決定されたあとです。この例外は、信頼できるコンポーネントと信頼できないコンポーネントの間でコンポーネント名(リソース名またはクラス・パッケージ名)の競合が検出され、そのリソースまたはクラスのロード要求が拒否されたことを示しています。
"resource \"" + name + "\" does not match trust level of other resources of the same name" "class \"" + packageName + "\" does not match trust level of other classes in the same package"
次の2つのSecurityException
がスローされるのは、信頼できないコンポーネントへのアクセスが以前に行われ、信頼できるコンポーネントをロードする試みが以前に検出され、混合コンポーネントの共存を許可することが決定され、信頼できるコンポーネントを含むJARが開かれ、信頼できるコンポーネントと信頼できないコンポーネントとの間でコンポーネント名の競合が検出された場合です。
"untrusted resource \"" + name + "\" in class path" "untrusted class package \"" + packageName + "\" in class path"
Trusted-Library
マニフェスト属性を使用するように簡単には更新できない混合コードJava Web Startアプリケーションがあります。all-permissions
セキュリティ・モデルを要求するようにJNLPを変更しなくても、サンドボックス内のJNLPに含まれるJARファイルに署名できますか。
回答: はい。ただし、いくつかの制限があります。サンドボックス内のJARファイルの署名は、all-permissions
セキュリティ・モデルを使用するJNLPファイル内の1つ以上の信頼できるJARファイルと同じ署名証明書を使用して行う必要があり、信頼できるJARファイルがJava Web Startによって開かれた後で、同じ署名者を共有するすべてのサンドボックス内のリソースがロードされる必要があります。つまり、信頼できるJARファイルが、Java Web StartのJAR検索順の前のほうに存在している必要があり、そうしないと単純な検索順とは無関係にJARインデックス機能を使用してロードされるようにトリガーされます。Java Web Startでは、まずメイン・アプリケーションJNLPのJARが、次にすべてのJNLP拡張が宣言された順番で検索されます。JNLP内では、まず「eager」というラベルの付いたJARファイルが検索され、次に「lazy」のJARファイルが検索され、続いて「part」機能を使用するというラベルの付いたすべてのJARファイルが検索されます。
私の電話にはJavaが搭載されています。それはこの問題の影響を受けますか。
回答: いいえ、Java MEには影響はありません。
Modifying a Manifest File (Javaチュートリアルの1セクションで、マニフェスト・ファイルの操作方法に関する情報が含まれています)。
Signing JAR Files (Javaチュートリアルの1セクション)。