新規 Web サービス Framework for Frameworks ハンドラーを既存の Web サービス記述言語カスタム・スキャナーと統合

このタスクについて

AppScan® Source を使用して JAX-RS または JAX-WS アプリケーションをスキャンする場合、アプリケーション内のいかなる脆弱性も見逃さないように、すべての Web サービスのエントリー・ポイントを収集できるようにすることが必要です。この文書では、そのための手法を説明します。ここで示す手順は、サポートされない Web サービスのフレームワークの分析に使用される新規 Framework for Frameworks (F4F) ハンドラーを、Web サービス記述言語 (WSDL) カスタム・スキャナーと統合するために実行します。

WSDL カスタム・スキャナーが、この新規 F4F ハンドラーに既に検出されている Web サービス・エントリー・ポイントと、WSDL ファイルに存在する Web サービス・エントリー・ポイントを区別できるようにするためには、この作業が必要です。WSDL カスタム・スキャナーはその情報を使用して、この新規 F4F ハンドラーによって既に分析された構成の検出結果を除去します。

Web サービス F4F ハンドラーの WSDL カスタム・スキャナーへの接続
シグニチャーのマッピング

Web サービス F4F ハンドラーの WSDL カスタム・スキャナーへの接続

始める前に

このセクションは、メインの F4F ハンドラーと合成メソッド生成が既に作成され、テスト済みであることを前提としています。

手順

プラグインから com.ibm.appscan.frameworks.wsdl.util (検出されたサービスを報告するための Helper API が含まれている) への依存関係を追加します。これは、walalib フォルダー内にもあります。
メイン・ハンドラー (F4FHandler クラスを拡張) 内の、handleApp() メソッドの先頭に、以下の行を追加します。
```
String filePath = WSDLReportingUtil.getServicesFilePath
     (getFrameworksInput().getFileLocs());
if (filePath!=null) {
WSDLReportingUtil.initXmlDocument(filePath);
}
```
これらの行によって、カスタム WSDL スキャナーが使用する一時ファイルが作成されます。
handleApp() メソッドの末尾に以下の行を追加して、F4F ハンドラーが終了する前に、報告されたサービスがすべて保存されるようにします。
```
WSDLReportingUtil.saveXmlDocument();
```
サービスを報告するには、以下の API のいずれかに対する WSDLReportingUtil API からの呼び出しを追加してください。
- reportService(String targetNameSpace, String serviceName, String methodSignature)
- reportService(String targetNamespace, String serviceName, String operationName, ArrayList<String> wsdlParams)
各部の意味は以下のとおりです。
- targetNameSpace は、サービスのターゲット名前空間です。これは、例えば JAX-WS ではアノテーション内に含まれるか、パッケージ名に一致します。
- serviceName は、サービスの名前です。これは、アノテーション内に格納されているか、またはサービス・クラス名と一致する場合があります。
- methodSignature は、単純化が加えられた WSDL ファイルのメソッドのシグニチャーです。
- operationName は、メソッドの名前です。これは、WSDL ファイルの 1 つのポート・タイプの操作名にリンクされます。
- wsdlParams は、単純な WSDL フォーマットのパラメーター・タイプのリストです。
現時点でカスタム WSDL スキャナーは、スタンドアローン・スキャナーとして、または Java/JSP スキャンの一部として作動します。新規 F4F Web サービス・ハンドラーが Java™ 以外の言語 (.NET など) を処理するように設計されている場合、WSDL カスタム・スキャナーが、適切なスキャン・タイプで呼び出されるように、以下のステップを実行します。
1. <data_dir>/ltd ディレクトリー(<data_dir> は AppScan® Source プログラム・データの場所です。説明はインストールとユーザー・データ・ファイルの場所)へ移動します。
2. すべてのファイルのバックアップ・コピーを作成して、予期しない問題の発生に備えます。
3. 適切なスキャン・タイプに該当する .ltd ファイルを開きます。例えば C++ では cpp.ltd ファイルを開きます。
4. <LanguageTypeDefinition> タグを閉じる前に、以下の行を追加します。
```
<Scanner name="wsdl"/>
```
5. file_extention_set_name 値をコピーします。この値は次のステップで必要になります。
6. file_extensions.xml を開き、前のステップでコピーした名前を持つ FileExtensionSet を探します。
7. ファイル内のそのポイントに、以下の行を追加します。
```
<FileExtension extension="wsdl" assess="true"/>
```
8. すべてのファイルを保存して、AppScan® Source を再始動します。この WSDL カスタム・スキャナーは、アプリケーションの完全スキャンの一環として実行されるようになります。

タスクの結果

この時点で、WSDL カスタム・スキャナーは、フレームワークによって実装されていない WSDL ファイルからの構成の検出結果のみを (「検出結果」ビューに) 表示します。アプリケーションに既に実装されている WSDL ファイルのサービスは、構成の検出結果として表示されません。これらは、新規 Web サービス F4F ハンドラーによって分析されます。

シグニチャーのマッピング

このタスクについて

WSDL カスタム・スキャナーは、報告されたメソッドを、対応する WSDL サービス、WSDL ポート・タイプ、および WSDL 操作と突き合わせようとします。このため、Web サービスは WSDL フォーマットで報告されます。分かりやすくするために、以下に挙げるいくつかの単純化が加えられています。

XSD プリミティブ型の場合、ターゲット名前空間を追加する必要がありません。代わりに名前のみ使用します (例えば string、int、float、double)。
コレクションおよび配列に対しては、タイプの後に [] を追加します (例えば string[]、int[] など)。
XSD 複合タイプに (JAX-B などのテクノロジーを使用して) マップされるクラス・タイプの場合、タイプは以下のように表示されます。
```
http//my-types/myxsdnamespace/:Customer
```
Java™ アノテーションの一部として名前空間が使用可能でなければなりません。名前空間が Java™ アノテーションの一部ではない場合、その名前空間はフレームワークの実装内容に応じて、呼び出し元サービスの名前空間またはパッケージ名と一致していなければなりません。

注: ほとんどの場合、マッピング・エラーが原因で、WSDL カスタム・スキャナーでは、報告された Web サービス API と関連する WSDL 操作との突き合わせができなくなります。この場合、追加の構成の検出結果が表示されます。この追加の検出結果は、誤検出であり、マッピング問題を示していると見なすことが適切です。

予期されるシグニチャーの表示方法が不明な場合は、WSDL ファイルそれ自体に対して AppScan® Source から WSDL スキャンを実行してください。これにより、WSDL サービスに含まれるすべての操作の検出結果が生成されます。各検出結果をクリックすると、「検出結果の詳細 (Findings Detail)」ビューにメソッド・シグニチャーが表示されます。