次の方法で共有


Windows のセキュリティ機能のテスト

アプリをテストして、Windows のセキュリティ機能と強力なアクセス制限リスト (ACL) を使っていることを確認します。

背景

Windows 既定のセキュリティ保護を変更すると、ユーザーが危険にさらされるリスクが増大します。

テストの詳細

BinScope Binary Analyzer と Attack Surface Analyzer を起動して、アプリのセキュリティをテストします。

問題への対応

テストで特定された問題をトラブルシューティングして修正します。アプリをリビルドして再テストします。

BinScope Binary Analyzer テスト

BinScope Binary Analyzer テストでは、アプリのバイナリ ファイルを検査して、攻撃や悪用に対してアプリの強度を上げるコーディングとビルドの手法をチェックします。

BinScope Binary Analyzer テストでは、以下のセキュリティ関連の機能が適切に使われているかをチェックします。

  • AllowPartiallyTrustedCallersAttribute
  • /SafeSEH 例外処理の保護
  • データ実行防止
  • アドレス空間レイアウトのランダム化
  • 共有されている PE セクションの読み取り/書き込み
  • AppContainerCheck
  • ExecutableImportsCheck
  • WXCheck

AllowPartiallyTrustedCallersAttribute

Windows アプリ認定キットのエラー メッセージ: APTCACheck Test failed

AllowPartiallyTrustedCallersAttribute (APTCA) 属性を使うと、署名されたアセンブリで、部分的に信頼されたコードから完全に信頼されたコードにアクセスできます。アセンブリに APTCA 属性を適用すると、アセンブリが有効な間は、部分的に信頼された呼び出し元からそのアセンブリにアクセスできます。これにより、セキュリティが侵害されるおそれがあります。

アプリがこのテストに合格しなかった場合の対処方法

プロジェクトに必要で、リスクをよく認識している場合を除いて、厳密な名前の付いたアセンブリでは APTCA 属性を使わないでください。APTCA 属性を使う必要がある場合は、すべての API が適切なコード アクセス セキュリティ要求によって保護されていることを確認します。アセンブリが Windows ストア アプリの一部となっている場合、APTCA の影響はありません。

注釈

このテストは、マネージ コード (C#、.NET など) でのみ実行されます。

/SafeSEH 例外処理の保護

Windows アプリ認定キットのエラー メッセージ: SafeSEHCheck Test failed

例外ハンドラーは、アプリがゼロ除算エラーなどの例外的な状況に陥った場合に実行されます。関数が呼び出されると例外ハンドラーのアドレスがスタックに格納されるため、悪意のあるソフトウェアがスタックを上書きしようとした場合、バッファー オーバーフローによる攻撃を受けやすくなることがあります。

アプリがこのテストに合格しなかった場合の対処方法

アプリをビルドするときに、リンカー コマンドの /SAFESEH オプションを有効にします。Visual Studio のリリース構成では、既定で、このオプションが有効になっています。このオプションが、アプリのすべての実行可能モジュールに対するビルド手順で有効になっていることを確認します。

注釈

このテストは、64 ビット バイナリまたは ARM チップセット バイナリでは実行されません。例外ハンドラーのアドレスがスタックに格納されないためです。

データ実行防止

Windows アプリ認定キットのエラー メッセージ: NXCheck Test failed

このテストでは、データ セグメントに格納されたコードが、アプリで実行されないことを確認します。

アプリがこのテストに合格しなかった場合の対処方法

アプリをビルドするときに、リンカー コマンドの /NXCOMPAT オプションを有効にします。Data Execution Prevention (DEP) をサポートするリンカー バージョンでは、既定で、このオプションが有効になっています。

注釈

DEP 対応の CPU でアプリをテストし、DEP の結果として見つかったエラーをすべて修正することをお勧めします。

アドレス空間レイアウトのランダム化

Windows アプリ認定キットのエラー メッセージ: DBCheck Test failed

ASLR (Address Space Layout randomization) を使うと、実行可能イメージがメモリの予測不可能な位置に読み込まれます。これにより、特定の仮想アドレスにプログラムを読み込むことを想定している悪意のあるソフトウェアは、予測どおりに動作しにくくなります。アプリとアプリで使うすべてのコンポーネントは、ASLR をサポートする必要があります。

アプリがこのテストに合格しなかった場合の対処方法

アプリをビルドするときに、リンカー コマンドの /DYNAMICBASE オプションを有効にします。アプリで使うすべてのモジュールでも、このリンカー オプションを使っていることを確認します。

注釈

通常、ASLR がパフォーマンスに影響を与えることはありません。ただし、場合によっては、32 ビット システムでわずかにパフォーマンスが向上することがあります。多くの画像がさまざまなメモリに読み込まれた非常に密集したシステムでは、パフォーマンスが低下する可能性があります。

このテストは、C# や .NET Framework などのマネージ コードで記述されたアプリでのみ実行されます。

共有されている PE セクションの読み取り/書き込み

Windows アプリ認定キットのエラー メッセージ: SharedSectionsCheck Test failed.

共有されている書き込み可能なセクションがあるバイナリ ファイルは、セキュリティの脅威です。共有する書き込み可能なセクションを含むアプリは、必須の場合を除き、ビルドしないでください。CreateFileMapping または MapViewOfFile を使って適切に保護された共有メモリ オブジェクトを作ります。

アプリがこのテストに合格しなかった場合の対処方法

アプリからすべての共有セクションを削除し、適切なセキュリティ属性を指定した CreateFileMapping または MapViewOfFile を呼び出して共有メモリ オブジェクトを作り、アプリをリビルドします。

注釈

このテストは、C や C++ などのアンマネージ言語で記述されたアプリでのみ実行されます。

AppContainerCheck

Windows アプリ認定キットのエラー メッセージ: AppContainerCheck Test failed.

AppContainerCheck は、実行可能バイナリの移植可能な実行可能ファイル (PE) ヘッダーで appcontainer ビットが設定されているかを検証します。 Windows ストア アプリでは、すべての .exe ファイルとすべてのアンマネージ DLL で appcontainer ビットが設定されていないと、正しく動作しません。

アプリがこのテストに合格しなかった場合の対処方法

ネイティブの実行可能ファイルでテストが不合格になった場合は、最新のコンパイラとリンカーを使ってファイルをビルドし、リンカーで /appcontainer フラグを使ってください。

マネージ実行可能ファイルでテストが不合格になった場合は、最新のコンパイラとリンカー (Microsoft Visual Studio など) を使って、Windows ストア アプリをビルドしてください。

注釈

このテストは、すべての .exe ファイル、およびアンマネージ DLL で実行されます。

ExecutableImportsCheck

Windows アプリ認定キットのエラー メッセージ: ExecutableImportsCheck Test failed.

移植可能な実行可能ファイル (PE) イメージで、実行可能コード セクションにインポート テーブルが置かれていると、このテストが不合格になります。 この問題は、Visual C++ リンカーの /merge フラグを /merge:.rdata=.text に設定して、PE イメージの .rdata マージを有効にすることが原因で生じることがあります。

アプリがこのテストに合格しなかった場合の対処方法

インポート テーブルを実行可能コード セクションにマージしないでください。Visual C++ リンカーの /merge フラグをチェックして、".rdata" セクションがコード セクションにマージされる設定になっていないことを確認してください。

注釈

このテストは、純粋なマネージ アセンブリを除き、すべてのバイナリ コードで実行されます。

WXCheck

Windows アプリ認定キットのエラー メッセージ: WXCheck Test failed.

このチェックでは、書き込み可能または実行可能としてマップされたページがバイナリに含まれていないことを確認します。 このチェックが不合格になるのは、書き込み可能または実行可能なセクションがバイナリに含まれている場合と、バイナリの SectionAlignmentPAGE_SIZE よりも小さい場合です。

アプリがこのテストに合格しなかった場合の対処方法

書き込み可能または実行可能なセクションがバイナリに含まれていないこと、バイナリの SectionAlignment の値が PAGE_SIZE の値以上であることを確認します。

注釈

このテストは、すべての .exe ファイル、およびネイティブのアンマネージ DLL で実行されます。

書き込み可能または実行可能なセクションは、エディット コンティニュ (/ZI) を有効にしてビルドした実行可能ファイルに含まれることがあります。エディット コンティニュを無効にすると、無効なセクションは含まれなくなります。

PAGE_SIZE は、実行可能ファイルの既定の SectionAlignment です。

Windows ストアで禁止されているファイル

Windows アプリ認定キットのエラー メッセージ: Banned File Check test failed.

Windows ストア アプリには、特定のファイルを含めることができません。そのようなファイルには、重要なセキュリティ、信頼性、その他の改善を提供する新しいバージョンがあります。Microsoft では、すべての開発者が最新バージョンを使っていることを確実にするために、Windows アプリ認定キットでこれらのファイルをブロックします。

現在、Windows アプリ認定キットの禁止されたファイルのチェック機能で次のファイルの有無がチェックされます。

Attack Surface Analyzer

Attack Surface Analyzer テストは、アプリのインストールと実行が終わった後、システム状態、ランタイム パラメーター、セキュリティ設定が可能なオブジェクトの変更をチェックして、特定のセキュリティ上の弱点がないかを検証します。こうした弱点を是正しても、パフォーマンスの低下を招くことはありません。アプリに、こうしたいずれかのセキュリティ上の弱点が存在する場合、Windows ストア用として認定することはできません。

Attack Surface Analyzer テストは、すべてのプログラミング言語に適用され、アプリ内にこれらのセキュリティ上の弱点がないかを検証します。

  • 脆弱な ACL を含むセキュリティ保護された実行可能ファイル
  • オブジェクトを含んでいて脆弱な ACL があるセキュリティ保護されたディレクトリ
  • 脆弱な ACL を含むセキュリテイ保護されたレジストリ キー
  • 非管理者のアカウントへアクセスを許可し、改ざんに対して脆弱なサービス
  • 間隔の短い再起動、または 24 時間ごとに 2 回以上の再起動を伴うサービス

脆弱な ACL を含むセキュリティ保護された実行可能ファイル

このテストは、管理者が所有する新規、または変更された実行可能ファイルすべてを対象としてアクセス制御リスト (ACL) をチェックすることにより、セキュリティ保護された実行可能ファイルの中に脆弱な ACL がないかを検証します。これらのファイルの ACL では、非管理者のユーザーによる変更が拒否されなければなりません。Attack Surface Analyzer は、実行可能ファイル (.exe) のほか、スクリプトやヘルプ ファイルなど実行可能なコンテンツを含むファイルもテストします。

アプリがこのテストに合格しなかった場合の対処方法

アプリ内にこうした弱点が検出された場合は、非管理者のアカウントについて次の権限の有無を確認し、削除します。GENERIC_ALLGENERIC_WRITEWRITE_OWNERWRITE_DACFILE_WRITE_ATTRIBUTESFILE_WRITE_EAFILE_APPEND_DATA、または FILE_WRITE_DATA, DELETE

注釈

脆弱な ACL があると、非管理者のユーザーにより実行可能ファイルの変更が可能になります。実行可能ファイルを変更すると、予期どおりに動作しなくなることがあります。アクセス権が正しく構成されていないと、攻撃者がファイルの内容の入れ替えや改ざんを行ったり、不正に動作させたりする可能性があります。

オブジェクトを含んでいて脆弱な ACL があるセキュリティ保護されたディレクトリ

このテストは、新規、または変更されたフォルダー階層を対象として ACL をチェックすることにより、セキュリティ保護されたディレクトリの中にオブジェクトが含まれていて脆弱な ACL がないかを検証します。階層 ACL (または継承 ACL) は、フォルダー内のすべてのファイルとフォルダーに対するアクセスを制御します。これらのフォルダーの ACL では、非管理者のユーザーによる各フォルダーやその内容の変更が拒否されなければなりません。

このテストでは、適切にセキュリティ保護されていない個々の実行可能ファイルやサブフォルダーにフラグを設定するのではなく、脆弱な ACL が含まれる、階層上で最も上に位置するフォルダーを識別します。

アプリがこのテストに合格しなかった場合の対処方法

アプリ内にこうした弱点が検出された場合は、テストで識別されたディレクトリに対するすべての非管理者アカウントについて次の権限の有無を確認し、以降、継承されないように、これらを削除します。GENERIC_ALLGENERIC_WRITEWRITE_OWNERWRITE_DACFILE_ADD_FILEFILE_ADD_SUBDIRECTORYFILE_WRITE_ATTRIBUTESFILE_WRITE_EAFILE_APPEND_DATAFILE_WRITE_DATAFILE_DELETE_CHILD、および DELETEこれには、ルート ディレクトリの ACL で Inherited フラグの変更が必要になる場合があります。

ルート ディレクトリの権限を修正した後、個々の実行可能ファイルの権限も修正する必要がある場合もあります。詳しくは「脆弱な ACL を含むセキュリティ保護された実行可能ファイル」を参照してください。

注釈

このテストでは、非管理者のユーザーに対して不適切な権限を認める脆弱な ACL をすべてに含むディレクトリとファイルの階層が識別されます。このような階層は、不正に継承された権限が原因で生じることがあります。したがって、子孫となるディレクトリやファイルでの権限を変更する前に、まず継承された権限を検証してください。

脆弱な ACL を含むセキュリテイ保護されたレジストリ キー

このテストは、Local Machine レジストリ ハイブ (HKLM) にある新規、または変更されたキーのアクセス制御リスト (ACL) をチェックすることにより、脆弱な ACL を含むセキュリテイ保護されたレジストリ キーを検出します。Local Machine レジストリ ハイブに対する書き込みアクセス権があるのは管理者だけです。

アプリがこのテストに合格しなかった場合の対処方法

すべての非管理者アカウントについて、テストで識別されたオブジェクトの各権限を削除します。GENERIC_ALLGENERIC_WRITEWRITE_OWNERWRITE_DACKEY_SET_VALUEKEY_CREATE_SUBKEY、および DELETE

注釈

このセクションに示すレジストリの値により、.exe や .dll など、実行可能ファイルの検索先を特定することができます。アプリでは、Local Machine レジストリ ハイブのレジストリ キーを使って、実行可能ファイルのパスの保存や読み取りを行うこともできます。このキーが攻撃者によって変更 (たとえば信頼できない実行可能ファイルのパスに値を変更) されると、アプリは誤ったファイルを実行する可能性があります。

レジストリ キーが実行可能ファイルを参照していると思われる場合、このテストでは、キーの ACL を調べて、非管理者のアカウントに不適切な権限が認められていないかを検証します。

非管理者のアカウントへアクセスを許可し、改ざんに対して脆弱なサービス

このテストでは、こうしたサービスを対象として ACL をチェックすることにより、非管理者アカウントへアクセスを許可するような新規、または変更されたサービスがないかを検出します。 新規のサービスには、バイナリ パス、ホスト DLL、レジストリ キー、またはサービスの内部に脆弱な ACL が存在してはなりません。脆弱な ACL があると、非管理者によりサービスの実行方法が改ざんされる可能性があります。

アプリがこのテストに合格しなかった場合の対処方法

「脆弱な ACL を含むセキュリティ保護された実行可能ファイル」の説明に従って、個々のファイルを修正してください。

注釈

各サービスには、汎用的な権限とサービス固有の権限の両方が関連付けられています。このテストでは、非管理者のアカウントに認められた不正な権限がないかを検証します。 権限が適切に保護されていないと、攻撃者がサービスを別の場所にリダイレクトして、起動時に信頼できないファイルを実行する可能性があります。

たとえば、攻撃者が ChangeServiceConfig を呼び出して、サービスの実行可能ファイルのパスを変更することが考えられます。

間隔の短い再起動、または 24 時間ごとに 2 回以上の再起動を伴うサービス

このテストでは、サービスの構成をチェックすることにより、再起動の頻度が高いサービスを検出します。サービスは、24 時間以内に 2 回以上再起動されてはなりません。

アプリがこのテストに合格しなかった場合の対処方法

サービスの Reset Period を変更して、24 時間以内に 2 回以上再起動されないようにします。

注釈

このテストでは、ASLR (Address Space Layout randomization) に関連する脆弱性を検出します。ASLR は、実行可能コードをメモリ内のランダムな場所に読み込むことにより、セキュリティの脆弱性を悪用しにくくする機能です。攻撃者によってサービスを繰り返し再起動することが可能な場合、ブルート フォース攻撃によって実行可能コードをあらゆる場所に読み込み、ASLR が攻略される可能性があります。

このテストでは、Service Failure Actions 構造の lpsaActions 要素を検証して、SC_ACTION_REBOOTSC_ACTION_RESTART の値をチェックします。これらの値は、ChangeServiceConfig2 を呼び出して構成できます。

テストでは、3 つ以上のアクションがないか、遅延値が 24 時間未満でないか、またサーバー リセット間隔が 24 時間未満でないかを判断します。