「プロパティー」ビュー: プロジェクトの選択

選択したプロジェクトの「概要」タブ

「概要」タブには、以下の内容が表示されます。

• プロジェクトの名前。プロジェクトの名前を変更するには、このフィールドに新しい名前を入力します。
• プロジェクトのファイル名およびパス
• プロジェクト・タイプ
• 構成: このセクションには、ターゲットの構成が表示されます。.NET および C++ Objective-C のプロジェクトの場合、このセクションには、「プロジェクト依存関係」タブに保存されているターゲットの構成が表示されます。その他のすべてのプロジェクト・タイプの場合、このセクションには、「デフォルト」が表示されます。
• フィルター・オプション:「外部ソースに含まれる検出結果をフィルタリング (Filter findings contained in external sources)」を選択すると、スキャンされたプロジェクトのソース・ファイルに含まれていないファイルで検出された結果がすべてフィルタリングされて除外されます。このオプションにより、検出結果が などのコンパイラー生成ファイルまたは一時ファイルASP.NETで報告されるプロジェクトで、不要な手間が軽減されます。
• 脆弱性分析キャッシュ (vulnerability analysis cache) オプション: 繰り返しスキャンしてカスタム・ルールを追加してから、ソース・コードを変更せずにスキャンをやり直すことにより、コード・ベースの評価を精緻化する場合は、脆弱性分析キャッシュを使用するようにプロジェクト・プロパティーを設定することにより、スキャン時間を大幅に短縮することができます。これを行うには、プロジェクト・プロパティーで、「脆弱性分析キャッシュを有効にする」チェック・ボックスを選択します。このチェック・ボックスを選択した後に初めてプロジェクトをスキャンすると、脆弱性分析キャッシュが作成されます。そのプロジェクトの以降のスキャンでは毎回、脆弱性分析キャッシュが使用されるため、スキャン時間が短縮されます。

  脆弱性分析キャッシュを消去するには、「キャッシュの消去」をクリックします。次回プロジェクトをスキャンするときには完全なスキャンが行われ、新しい脆弱性分析キャッシュが作成されます。以下の場合は、キャッシュを消去することをお勧めします。

  • 前回のスキャン以降に、プロジェクトに含まれるソース・コードが変更されている場合。
  • プロジェクト構成に変更を加えた場合 (ソース・ファイルを追加または削除するなど)。
  • コード構成オプションを変更した場合。例えば、Java™ をスキャンしていて、クラスパスが変更された場合や、C または C++ をスキャンしていて、include パスまたはプリプロセッサー定義を変更した場合に、キャッシュを消去したほうがよいことがあります。
  注: カスタム・ルール・ウィザードでカスタム・ルールを作成するときに、「キャッシュの消去」チェック・ボックスを選択することによって、脆弱性分析キャッシュを消去することもできます。
• 文字列分析: 文字列分析は、Java または Microsoft™ .NET プロジェクトでの文字列操作をモニターします。また、サニタイザーとバリデーターのルーチンの自動検出を可能にします。この検出を使用すれば、誤検出と検出漏れを減らすことができます。文字列解析を有効にするには、「文字列解析で検証プログラムやサニタイズ・プログラムの関数を検索できるようにする」チェック・ボックスを選択します。「インポートされたルールをグローバル・スコープに適用する」チェック・ボックスは、検出されたサニタイズ・プログラムまたは検証プログラムのルーチンを単一のプロジェクトに適用するか、あるいはグローバル・レベルで (すべてのプロジェクトに) 適用するかを決定します。
  注: 文字列解析のアプリケーションはスキャンに時間がかかる可能性があります。そのため、必ず、コード変更後に適用してから、以降のスキャンでは無効にすることをお勧めします。また、検出されたルーチンは 提案 として表示し、監査員がそれらを確認する必要があります。これらのルーチンは、「カスタム・ルール」ビューで表示できます。
• ファイル・エンコード: プロジェクト内のファイルの文字エンコードは、AppScan ソース がファイルを適切に読み取る (そして、例えば、それらを「ソース」ビューに正しく表示する) ことができるように設定する必要があります。
  注: AppScan ソース プロジェクトのデフォルトのファイル・エンコードは、ISO-8859-1 です。デフォルトのファイル・エンコードは、「全般設定」ページで変更できます。

フィルター

このタブで、選択したプロジェクトの既存のフィルターを指定できます。また、フィルターの適用方法も指定できます (フィルターは直接適用することも、反転して適用することもできます)。フィルターについては、トリアージおよび分析を参照してください。また、グローバル・フィルターの適用について詳しくは、グローバル・フィルターの適用を参照してください。

パターン・ルールとパターン・ルール・セット

「エクスプローラー」ビューでプロジェクトを選択した場合、「プロパティー」ビューの「パターン・ルールとパターン・ルール・セット」タブで、そのプロジェクトがスキャンされる際に適用するパターン・ルールとパターン・ルール・セットを追加できます。パターン・ベースのスキャンを使用して、検出結果として表示させたいテキスト・パターンを検索します。個々のルールとルール・セットをアプリケーションとプロジェクトの両方に適用できます。パターン・ベースの分析については パターン・ベースのルールによるカスタマイズを、「プロパティー」ビューでのルールとルール・セットの適用方法については パターン・ルールとパターン・ルール・セットの適用を参照してください。

ファイル拡張子

このタブを使用して、プロジェクトの有効なファイル拡張子を構成または追加します。また、スキャンからファイルを除外したり、拡張子を Web ファイルとして指定したりすることもできます。

「ファイル拡張子」セクションには、現行プロジェクト・タイプの プロジェクト・ファイル拡張子 設定ページでグローバルに設定された拡張子がリストされます (「ファイル拡張子のセット」メニューを使用して、別のプロジェクト・タイプのファイル拡張子を選択できます)。現行プロジェクトのスキャンから拡張子を除外するには、リストでその拡張子を選択し、「拡張子の除外」をクリックします。これにより、その拡張子はタブの「除外する拡張子」セクションにリストされます。

プロジェクトの拡張子を追加するには、「追加の拡張子」セクションで「拡張子の追加」を選択してから、ファイル拡張子を入力し、その拡張子を持つファイルがスキャンされるか、Web ファイルと見なされるか、または除外されるかを示します。

ソース

スキャンに含めるソースを指定します。

• 作業ディレクトリー:AppScan ソース プロジェクト・ファイル (ppf) の格納場所であり、すべての相対パスの基準になります。
• 「ソース・ルートの追加」および「ソース・ルートの削除」: 「ソース」タブには、プロジェクト構成ウィザードで現行プロジェクトに対して設定されたプロパティー、またはインポートされた ppf で定義されているプロパティーが表示されます。

  「ソース・ルートの削除」は、「ソース・ルート」アイコンが選択されている場合のみ使用可能です。これを使用して、ソース・コードのルート・ディレクトリーを削除します。

• ソース・ルートの検索 (Java プロジェクトのみ):AppScan Source for Analysis がすべての有効なソース・ルートを自動的に検出できるように設定します。
• プロジェクト・ファイルは、「ソース・ルート」アイコンの下に表示されます。スキャンから除外されたファイルには、赤いファイル・アイコンが付いています。 (除外済みファイルを右クリックすると、そのメニューで「除外」は無効に、「含める」は有効になっています)。組み込みファイルを除外するには、ファイルを右クリックして、メニューで「除外」を選択します。除外済みファイルを組み込むには、ファイルを右クリックして、メニューで「含める」を選択します。

JavaServer Page (JSP) プロジェクト依存関係

「JSP プロジェクト依存関係」タブには、指定した JSP プロジェクトに対して設定されたプロパティーが表示されます。

• Web (JSP) コンテンツを含む: プロジェクトが JavaServer Pages を含む Web アプリケーションであるかどうかを識別します。
• Web コンテキスト・ルート: 1 つの WAR ファイル、または WEB-INF ディレクトリーを含むディレクトリーです。Web コンテキスト・ルートは、有効な Web アプリケーションのルートである必要があります。
• JSP コンパイラー: 製品に付属の Tomcat 7 が、デフォルトの JSP コンパイラー設定です (デフォルト JSP コンパイラーは「Java およびJSP」設定ページで変更できます)。AppScan ソース でサポートされるコンパイラーについて詳しくは、システム要件およびインストールの前提条件 を参照してください。

  Apache Tomcat バージョン 7 および 8 は、AppScan ソース のインストール済み環境に含まれています。「Tomcat 7」および「Tomcat 8」設定ページが未構成の場合、AppScan ソース は、提供されている Tomcat JSP コンパイラー (現在デフォルトとしてマーク) を使用して JSP ファイルをコンパイルします。外部のサポート対象 Tomcat コンパイラーを使用する場合は、「Tomcat」設定ページを使用してローカルの Tomcat インストールを参照します。

  Oracle WebLogic サーバー または WebSphere® アプリケーション・サーバー を使用する場合は、適切な設定ページで、アプリケーション・サーバーのローカルのインストール済み環境を示すように構成して、分析時にそれを JSP コンパイルに使用できるようにする必要があります。この構成をまだ完了していない場合は、JSP コンパイラーの選択時に、構成を完了するように求めるメッセージが表示されます。メッセージ内の「はい」をクリックすると、該当する設定ページに進みます。「いいえ」をクリックすると、JSP コンパイラーの選択項目の隣に警告リンクが表示されます (リンクを選択すると、設定ページが開きます)。

プロジェクト依存関係

「プロジェクト依存関係」タブには、プロジェクト・プロパティーが表示されます。このタブで構成する設定は、以下のように言語によって異なります。

• 「オプション」を使用すると、追加で必要なコンパイラー・パラメーターを選択できます。
• JDK 設定は Java に固有です。
• プリプロセッサー定義は C/C++ コードに固有です。プリプロセッサー定義を指定するときは、コンパイラーの -D オプションを含めないでください (例えば -Da=definition1 の代わりに a=definition1 を指定してください)。複数の定義を指定するときは、セミコロンで区切ったリストを使用します。
• ターゲットの構成は、.NET および C++Objective-C のプロジェクトでのみ使用できます。

コンパイル

• オプション: プロジェクト構成に必要なその他のコンパイル・パラメーター。
• JDK の使用 (Use JDK): 「設定」で構成されている、プロジェクトのコンパイルに使用される JDK を識別します。設定を参照してください。

  Java プロジェクトは、ローカルの Java Development Kit (JDK) の場所を参照する可能性があります。プロジェクトをサーバーに移動すると、JDK パスは無効になります。ローカル・プロジェクトをサーバーに転送するには、指名されている JDK を指定するプロジェクトごとに、デフォルトの JDK パスを識別する必要があります。

  注: 製品に付属する JSP プロジェクトのデフォルト・コンパイラーは、Tomcat 7 です。これには、Java バージョン 1.6 以上が必要です。Tomcat 7 をデフォルトのまま使用している場合、古い JDK を選択すると、以下のスキャン中のコンパイル・エラーが発生します。
• 検証:「検証」によって、プロジェクト依存関係が正しく構成されていることを確実にします。Java プロジェクト内でソースとクラス・パスの間の構成競合と、コンパイル・エラーをチェックします。クラスパス内のクラスが、ソース・ルートで重複している場合、競合が存在します。(競合が存在する場合、クラス・パスを変更して競合しているクラスを削除します)。

  競合をチェックした後で、「検証」をクリックして、プロジェクトをコンパイルできるかどうか、およびコンパイル・エラーがレポートされるかどうかを判別します。

最適化

• プリコンパイル済みクラス: スキャン中にコンパイルするのではなく、プリコンパイル済みの Java または JSP クラス・ファイルを使用します。このオプションを選択すると、ソース・ステージ・オプションが無効になります。
• コンパイル・エラーの影響を最小化するためにソース・ファイルをステージする:AppScan ソース がステージング・ディレクトリーにソースをコピーするかどうかを制御します。

  「ディレクトリーと一致しないパッケージの修正」を選択すると、Java コンパイラーは各ソース・ファイルを開くことが必要になります。

  「スキャンの合間にステージング領域をクリーンアップ」によって、スキャンと次のスキャンの間のパフォーマンスが向上します。

プリコンパイル・タブ (ASP.NET のみ)

プリコンパイルは、Web サイトの特殊なページ (デフォルトでは precompile.axd) に対して HTTP 要求を出すことによって実行されます。このページは、web.config で指定された特殊な HTTP ハンドラーによって処理されます。このハンドラーは、client.aspx ファイルを含めたサイト全体をコンパイルして、.NET フレームワーク・ディレクトリー内の ASP.NET 一時ファイル・ディレクトリーに入れます。そこでファイルはすべてスキャンされます。

ASP.NET 1.1 をスキャンするには、Web サイトをコンパイルしてデバッグ情報を蓄積するように Web サイトの準備をする必要があります。この場合、Web サイトをコンパイルしてがデバッグ情報蓄積するという事実自体が、セキュリティーの脆弱性になります。これはスキャンに必要なことなので、この脆弱性は無視して構いません。ただし、デプロイされたアプリケーションが、web.config で debug=true と指定してコンパイルされていないことを確認してください。

ASP.NET 1.1 Web サイトをプリコンパイルするには、web.config ファイル内で以下のエレメントを <system.web> エレメントの子として追加します。

<httpHandlers><add verb="*" path="precompile.axd"
type="System.Web.Handlers.BatchHandler"/></httpHandlers>

また、コンパイル・エレメントで debug=true と設定する必要があります。例:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<system.web>
		<httpHandlers><add verb="*" path="precompile.axd"
		type="System.Web.Handlers.BatchHandler"/>
		</httpHandlers>
			<compilation
				defaultLanguage="c#"
				debug="true"
			/>
...

このエレメントは、precompile.axd ページが .Net の特殊な System.Web.Handlers.BatchHandler クラスによって処理されることを、Web サイトに対して指定します。このクラスは、Web サイトのコンテンツを一時 ASP.NET ファイル・ディレクトリーにプリコンパイルします。

• Web サイト: サイトをプリコンパイルするよう、ターゲットに要求します。デフォルトの場所は precompile.axd です。 Precompile.axd は仮想ファイルであり、web.config ファイルで指定されたファイルにマップします。
• 出力ディレクトリー: プリコンパイルでターゲットとするディレクトリー。AppScan Source は、このディレクトリーでプリコンパイルの出力を特定します。
• ASP.NET Web サイトをプリコンパイルする (Precompile the ASP.NET website):AppScan ソース スキャン中に自動的にサイトをプリコンパイルし、プリコンパイルされた出力をスキャンします。
• プリコンパイルが失敗した場合はスキャンを停止する (Stop scan if precompile fails):「ASP.NET Web サイトをプリコンパイルする (Precompile the ASP.NET website)」と「プリコンパイルが失敗した場合はスキャンを停止する (Stop scan if precompile fails)」を選択すると、プリコンパイルが失敗した場合、スキャンが停止します。これを選択しない場合、プリコンパイルが失敗すると、スキャンは Web サイトの 1 次出力に対してのみ続行されます。
• 今すぐコンパイルする (Compile Now): スキャンの前に、現在の設定に基づいてプリコンパイルをテストし、プリコンパイルが成功することを確認します。「プリコンパイル出力 (Precompile Output)」ペインに、コンパイル出力が表示されます。
• 追加アセンブリー (Additional Assemblies): .NET プロジェクト・タイプの場合、追加でスキャンするアセンブリーを指定します。
• プロジェクト参照 (Project References): .NET アセンブリー・プロジェクトと既存の .NET プロジェクトで参照されているアセンブリーの検索先ディレクトリーをリストします。