セキュリティー用の JAR ファイルマニフェストの属性

Rich Internet Application の開発および配備 > セキュリティー用の JAR ファイルマニフェストの属性

概要
Permissions 属性
Codebase 属性
Application-Name 属性
Application-Library-Allowable-Codebase 属性
Caller-Allowable-Codebase 属性
Trusted-Only 属性
Trusted-Library 属性
関連情報

概要

JAR ファイルマニフェストには、セキュリティーと構成の情報など、JAR ファイルのコンテンツに関する情報が含まれています。このセクションで説明するマニフェスト属性を使用すると、ブラウザから RIA を実行する際のセキュリティーが向上します。これらの属性は、JAR ファイルが署名される前にマニフェストに追加してください。JAR マニフェストファイルに属性を追加する方法については、Java チュートリアルの「Modifying a Manifest File」を参照してください。

注: これらの属性は、署名付きのアプレットおよび Java Web Start アプリケーションに適用されます。スタンドアロンの Java アプリケーションでは、これらの属性は無視されます。

Permissions 属性

Permissions 属性は、RIA によってその実行時にリクエストされるアクセス権のレベルが、JAR ファイルの作成時に設定されたアクセス権のレベルと一致していることを検証するために使用されます。この属性を使用すると、自身の証明書で署名されているアプリケーションが再配備されたり、異なる特権レベルで実行されたりすることを防げます。この属性は、次のいずれかの値に設定します。

sandbox - RIA がセキュリティーサンドボックス内で実行され、追加のアクセス権を必要としないことを示します。
all-permissions - RIA がユーザーのシステムリソースへのアクセスを必要とすることを示します。

この値は、JNLP ファイルまたは applet タグでリクエストされているアクセス権のレベルと一致する必要があり、アクセス権のレベルがリクエストされていない場合は、デフォルトのアクセス権と一致する必要があります。それ以外の場合は、エラーが表示され、RIA はブロックされます。applet タグでアクセス権のレベルを設定する方法については、「Deploying with the Applet Tag」を参照してください。permissions パラメータが設定されていない場合、署名付きアプレットのデフォルトは all-permissions、署名なしのアプレットのデフォルトは sandbox になります。アクセス権のレベルのリクエストに使用される security 要素については、「Structure of the JNLP File」を参照してください。その要素が存在しない場合、アクセス権のレベルはデフォルトで sandbox になります。

Java コントロールパネルの「セキュリティーレベル」スライダが「非常に高」に設定されている場合は、Permissions 属性が必要です。それが存在しない場合、RIA はブロックされます。

「高」および「中」のセキュリティーレベルでは、Permissions 属性が存在しない場合、セキュリティープロンプトに、見つからなかった属性に関する黄色の警告が含まれ、RIA によってリクエストされたアクセス権のレベルが使用されます。

Codebase 属性

Codebase 属性は、JAR のコードベースを特定のドメインに制限するために使用されます。この属性を使用すると、悪意のある目的でアプリケーションが別の Web サイトに再配備されることを防げます。

注:Codebase 属性でセキュアなサーバー (HTTPS など) を指定しない場合は、コードが Man-in-the-Middle (MITM) 攻撃スキームで転用される可能性があるという多少のリスクが生じます。

この属性は、アプリケーションが置かれているドメイン名または IP アドレスのどちらかに設定します。ポート番号を含めることもできます。複数の場所を指定する場合は、それらの値を空白で区切ります。ドメイン名の先頭にのみ、アスタリスク (*) をワイルドカードとして使用できます。次の表に、サンプル値とそれらに一致するものを示します。

値	一致するもの	一致しないもの
*	すべてのドメイン
https://*.example.com	https://a.example.com https://a.b.example.com	http://a.example.com http://a.b.example.com
www.example.com	https://www.example.com、http://www.example.com	http://example.com http://example.net
www.example.com:8085	https://www.example.com:8085、http://www.example.com:8085	http://www.example.com
*.example.com	https://a.example.com、http://a.example.com https://a.b.example.com、http://a.b.example.com https://example.com、http://example.com	http://example.net
127.0.0.1	http://127.0.0.1 http://127.0.0.1:8080 http://127.0.0.1:80	http://localhost
127.0.0.1:8080	http://127.0.0.1:8080	http://127.0.0.1 http://127.0.0.1:80

Codebase 属性の値は、RIA がアクセスされる実際の場所と一致する必要があります。それ以外の場合は、エラーが表示され、RIA はブロックされます。この属性が存在しない場合は、警告が Java コンソールに書き込まれ、applet タグまたは JNLP ファイルに指定されたコードベースが使用されます。

Application-Name 属性

Application-Name 属性は、署名付き RIA のタイトルを指定するためにセキュリティープロンプトで使用されます。ユーザーが RIA を信頼して実行することを簡単に決められるように、この属性の使用をお勧めします。この値には、任意の有効な文字列を指定できます。例:

Application-Name: Hello World

Application-Name 属性が JAR ファイルマニフェストに含まれていない場合は、警告が Java コンソールに書き込まれ、Main-Class 属性の値が使用されます。どちらの属性もマニフェストに含まれていない場合は、セキュリティープロンプトに表示されるタイトルはありません。署名されていない RIA にはタイトルが表示されません。

Application-Library-Allowable-Codebase 属性

Application-Library-Allowable-Codebase 属性は、署名付き RIA が見つかると予想される場所を識別します。この属性は、RIA の JAR ファイルが、RIA を起動する JNLP ファイルまたは HTML ページとは異なる場所にある場合にユーザーに表示されるセキュリティープロンプトの「場所」フィールドにリストされる内容を決めるために使用されます。この属性は、JAR ファイル、JNLP ファイル、および HTML ページが置かれているドメインに設定します。複数のドメインを指定するには、それらのドメインを空白で区切ります。例:

Application-Library-Allowable-Codebase: https://host.example.com *.samplehost.com/apps

Application-Library-Allowable-Codebase 属性が存在し、RIA が起動される場所と一致する場合は、プロンプトの「場所」フィールドに 1 つのホストがリストされます。この属性が存在しないか、RIA がその属性で指定されていない場所から起動される場合は、JAR ファイルと JNLP ファイルまたは HTML ページの場所に対応する複数のホストがプロンプトの「場所」フィールドにリストされます。複数のホストが表示される場合は、今後のプロンプトを非表示にするオプションはユーザーに表示されません。セキュリティープロンプトにホストが 1 つだけ表示され、ユーザーが RIA を信頼して実行するかどうかを簡単に決められるように、この属性の使用をお勧めします。

RIA の JAR ファイルが、RIA を起動する JNLP ファイルまたは HTML ページと同じ場所にある場合、この属性は必要ありません。

指定できる値については、「Codebase 属性」を参照してください。

Caller-Allowable-Codebase 属性

Caller-Allowable-Codebase 属性は、JavaScript コードが RIA への呼び出しを行えるドメインを識別するために使用されます。この属性は、JavaScript コードをホストするドメインに設定します。Caller-Allowable-Codebase 属性で指定されたドメインに置かれていない JavaScript コードから呼び出しが行われた場合、その呼び出しはブロックされます。複数のドメインを指定するには、それらのドメインを空白で区切ります。例:

Caller-Allowable-Codebase: host.example.com 127.0.0.1

Caller-Allowable-Codebase 属性が存在しない場合は、JavaScript コードが RIA への呼び出しを試みたときにセキュリティー警告がユーザーに表示されます。ユーザーはその呼び出しを許可するか、またはブロックするかを選択できます。署名されていない RIA では、RIA へのアクセスを必要とする JavaScript コードが、RIA のメイン JAR ファイルと同じ場所にある必要があります。それ以外の場合、ユーザーはアクセスを許可するよう求められます。

指定できる値については、「Codebase 属性」を参照してください。

Trusted-Only 属性

Trusted-Only 属性は、信頼できないクラスまたはリソースがアプレットまたはアプリケーションでロードされることを防ぐために使用されます。この属性の値は true に設定します。例:

Trusted-Only: true

この属性は、特権付きのアプリケーションまたはアプレットが転用されて、信頼できないコンポーネントが追加されることを防止します。アプリケーションまたはアプレット内のクラスとリソースはすべて署名付きで、すべてのアクセス権をリクエストするものである必要があります。

Trusted-Library 属性

Trusted-Library 属性は、信頼できないコンポーネントを許可するように設計されているアプリケーションとアプレットに使用されます。警告ダイアログは表示されず、アプリケーションまたはアプレットは、信頼できないクラスやリソースを含む JAR ファイルをロードできます。この属性の値は true に設定します。例:

Trusted-Library: true

この属性は、特権付きのアプリケーションまたはアプレット内のコンポーネントが転用されて、信頼できないコンポーネントが追加されることを防止します。このマニフェスト属性を含む JAR ファイル内のクラスとリソースはすべて署名付きで、すべてのアクセス権をリクエストするものである必要があります。

混合コードのアプリケーションまたはアプレットでは、特権付きのクラスとリソースはすべて、Trusted-Library 属性を含む JAR ファイル内に含める必要があります。この属性は、特権付き Java コードとサンドボックス Java コード間の呼び出しに使用されます。Java コードを呼び出す JavaScript コードが含まれている場合は、「Caller-Allowable-Codebase 属性」を参照してください。

信頼できるライブラリ JAR はすべて、そのアプリケーションインスタンスまたはアプレットインスタンスに固有の個別の専用クラスローダー内にロードされます。この Trusted-Library ローダーが、Web Start またはアプレットの通常のクラスローダーの親になりました。元の検索順との下位互換性を保てるように、両方のローダーが協調して共通のクラスパスを実装しています。以前のリリースと同様、JAR ファイルは遅延ダウンロードを使用し、リクエストされたクラスとリソースを見つけるため必要に応じて開かれます。

Trusted-Library マニフェスト属性を付ける予定の JAR ファイル内のコードで、クラスローダーに依存する呼び出し (単一パラメータ版の Class.forName()、Class.getResource()、Class.getResourceAsStream()、java.util.ResourceBundle.getBundle() のいくつかのバリアントなど、直接の呼び出し元が定義しているローダーを基準にして動作するすべてのメソッド) を使用している場合には、コードを若干変更しなければいけない可能性があります。変更を加える必要があるのは、Trusted-Library でない (したがって Web Start またはアプレットの通常のクラスローダーによってロードされる) JAR ファイル内で、リクエストされたクラスやリソースが見つかる可能性がある場合だけです。

Trusted-Library 内のコードで通常のローダーを検索するには、Thread.currentThread().getContextClassLoader() を呼び出します。ただし、getContextClassLoader() から null が返される状況がまれに発生します。たとえば、ガベージコレクタが JRE システムスレッドを使って、到達不可能なインスタンスの Object.finalize() メソッドを呼び出したときに、これが発生する可能性があります。

メソッド Class.getResource() または Class.getResourceAsStream() を ClassLoader の対応するメソッドに変換する必要がある場合には、これら 2 つのメソッドのドキュメントの説明に従って、文字列パラメータを忘れずに調整してください。元のリソース名が '/' で始まっている場合、それは絶対名なので、先頭の '/' を単純に削除する必要があります。それ以外の場合、getResource 呼び出しのターゲットとなっていたクラスインスタンスが、名前付きパッケージに含まれているかどうかを判別します。それが配列の場合、まずは配列のベースとなるコンポーネントの型を判別すべきです。クラスまたはコンポーネントの型のインスタンス上で Class.getName() を呼び出します。クラス名に '.' 文字が 1 つでも含まれている場合、名前付きパッケージ内にそのクラスは含まれており、元のリソース名の先頭にそのパッケージ名を追加する必要があります。パッケージ名を判別するには、末尾の '.' 文字とそれ以降の文字をすべて削除します。次に、残った '.' 文字をすべて '/' 文字に置き換えます。最後に、'/' を末尾に 1 つ追加したあと、元のリソース名文字列を追加します。これで、この新しい文字列を、ClassLoader バージョンの getResource() または getResourceAsStream() メソッドに渡すことができます。

一般に、信頼できるライブラリ内のコードが、注意深くセキュアな方法で記述されるように、またその他の点では、アプリケーションの一部であり、通常のローダーによってロードされる残りの任意の JAR から、個別のクラスローダーインスタンス内にロードされる互換性を保てるように、注意を払う必要があります。