JScript のセキュリティに関する考慮事項
更新 : 2007 年 11 月
どの言語においても、安全なコードを作成することが重要な課題となります。JScript では、推奨される手順の使用を開発者に強制しないため、気付かないうちに安全でない方法で言語を使用してしまう可能性のある領域がいくつかあります。JScript は、セキュリティの確保も 1 つの目標としてデザインされていますが、最大の目標は、便利なアプリケーションを迅速に開発できるようにすることです。場合によっては、この 2 つの目標が相反することがあります。
セキュリティに影響を与える可能性のある、いくつかの主な問題を以下に示します。これらの問題を認識しておくことによって、セキュリティ上の危険を回避できます。eval メソッドを除くこれらの問題は、.NET Framework の新機能が導入されたために考慮することが必要になりました。
eval メソッド
JScript で最も誤用されやすい機能は eval メソッドです。このメソッドでは、JScript のソース コードを動的に実行できます。eval メソッドを使用する JScript アプリケーションは、プログラムから渡されるどのようなコードでも実行できるため、eval メソッドのすべての呼び出しにセキュリティ上の危険性があります。どのようなコードでも実行する柔軟性がアプリケーションで必要とされない限り、アプリケーションが eval メソッドに渡すコードを明示的に記述することを検討してください。
eval メソッドの完全な柔軟性を必要とするアプリケーションのセキュリティを向上させるために、eval に渡されるコードは、既定では制限付きコンテキスト内で実行されます。制限付きのセキュリティ コンテキストにより、ファイル システム、ネットワーク、ユーザー インターフェイスなどのすべてのシステム リソースへのアクセスを禁止できます。これらのリソースにアクセスしようとすると、セキュリティ例外が生成されます。ただし、eval メソッドで実行されるコードは、ローカル変数とグローバル変数を変更することはできます。詳細については、「eval メソッド」を参照してください。
以前のバージョンの JScript で記述されたコードでは、呼び出し元のコードと同じセキュリティ コンテキストでコードを実行するために eval メソッドが必要な場合があります。この動作を有効にするために、省略可能な 2 番目のパラメータとして文字列 "unsafe" を eval メソッドに渡すことができます。"unsafe" モードでは、コード文字列が呼び出し元のコードと同じアクセス許可で実行されるため、既知のソースから取得したコード文字列だけを実行する必要があります。
セキュリティ属性
.NET Framework のセキュリティ属性を使用して、JScript の既定のセキュリティ設定を明示的にオーバーライドできます。ただし、この操作を確実に理解していない限り、既定のセキュリティ設定は変更しないでください。特に、AllowPartiallyTrustedCallers 属性 (APTCA) カスタム属性の使用は避けてください。これは、通常、信頼できない呼び出し元は JScript コードを安全に呼び出すことができないためです。APTCA を使用して信頼できるアセンブリを作成し、そのアセンブリがアプリケーションによって読み込まれた場合は、部分的に信頼されている呼び出し元から、アプリケーションの完全に信頼できるアセンブリにアクセスできてしまいます。詳細については、「安全なコーディングのガイドライン」を参照してください。
部分的に信頼されるコードとホストされる JScript コード
JScript をホストするエンジンでは、呼び出されたすべてのコードによって、グローバル変数、ローカル変数、オブジェクトのプロトタイプ チェインなど、エンジンの一部を変更できます。また、関数は、渡される expando オブジェクトの expando プロパティまたはメソッドを変更できます。このため、JScript アプリケーションが、部分的に信頼されるコードを呼び出す場合や、他のコードで記述されたアプリケーション (Visual Studio for Applications [VSA] ホストからなど) で実行される場合は、アプリケーションの動作が変更される可能性があります。
上記の問題点を考慮すると、アプリケーションまたは AppDomain クラスのインスタンス内の JScript コードは、アプリケーション内の他のコードと同等以下の信頼レベルで実行する必要があります。他のコードよりも高い信頼レベルで実行される場合は、他のコードが JScript クラスのエンジンを操作し、それによってエンジンがデータを変更し、アプリケーション内の他のコードに影響を与える可能性があります。詳細については、「_AppDomain」を参照してください。
アセンブリ アクセス
JScript は、厳密な名前とテキストの簡易名の両方を使用してアセンブリを参照できます。厳密な名前参照には、アセンブリのバージョン情報と、アセンブリの整合性および ID を確認する暗号署名が含まれています。アセンブリを参照する場合は簡易名を使用する方が簡単ですが、厳密な名前を使用すると、機能の異なる他のアセンブリが同じ簡易名を持つ場合にコードが保護されます。詳細については、「方法 : 厳密な名前のアセンブリを参照する」を参照してください。
スレッド処理
JScript ランタイムは、スレッド セーフ機能を持つようにはデザインされていません。このため、マルチスレッド JScript コードは、予期しない動作をする場合があります。JScript でアセンブリを開発する場合は、マルチスレッド コンテキストでそのアセンブリが使用される可能性があることに注意してください。Mutex クラスなど、System.Threading 名前空間にあるクラスを使用して、アセンブリ内の JScript コードが適切な同期をとって実行されるようにする必要があります。
適切な同期コードを記述することはどの言語でも難しいため、必要な同期コードの実装方法をよく理解していない限り、JScript で汎用アセンブリを記述しないでください。詳細については、「System.Threading」を参照してください。
.gif "メモ") メモ : |
|---|
ASP.NET では生成するすべてのスレッドの同期を管理するため、JScript で作成された ASP.NET アプリケーションの同期コードを記述する必要はありません。ただし、JScript で作成された Web コントロールはアセンブリのように動作するため、これらのコントロールには同期コードが含まれている必要があります。 |
ランタイム エラー
JScript は、柔軟に型指定された言語であるため、Visual Basic や Visual C# などの他の一部の言語よりも型の不一致が許容されます。型の不一致によってアプリケーションでランタイム エラーが発生する場合があるため、コードの開発時には、発生する可能性のある型の不一致を検出することが重要です。コマンド ライン コンパイラで /warnaserror フラグを使用するか、ASP.NET ページの @ Page ディレクティブの warninglevel 属性を使用できます。詳細については、「/warnaserror」および「@ Page」を参照してください。
互換モード
互換モードで /fast- オプションを使用してコンパイルされたアセンブリは、既定の高速モードでコンパイルされたアセンブリよりも暗号化の度合いが低くなります。/fast- オプションを使用すると、既定では使用できない言語機能が有効になります。JScript Version 5.6 以前のバージョン用に記述されたスクリプトとの互換性を実現するためには、これらの機能が必要になります。たとえば、互換モードでは、String オブジェクトなどの組み込みオブジェクトに expando プロパティを動的に追加できます。
互換モードは、JScript のレガシ コードからスタンドアロン実行可能ファイルを作成する場合に役立ちます。新しい実行可能ファイルまたはライブラリを開発する場合は、既定のモードを使用してください。既定のモードでは、安全なアプリケーションを作成できるだけでなく、パフォーマンスや他のアセンブリとの互換性も向上します。詳細については、「/fast」を参照してください。
参照
概念
前のバージョンの JScript で作成されたアプリケーションのアップグレード