Intégration d'un nouveau gestionnaire Framework for Frameworks de services Web au scanner personnalisé WSDL (Web Service Description Language) existant

Pourquoi et quand exécuter cette tâche

Lors de l'examen d'une application JAX-RS ou JAX-WS avec AppScan® Source, vous devez vérifier que vous pouvez capturer tous les points d'entrée de service Web, de sorte que vous ne manquiez aucune vulnérabilité dans votre application. Ce document décrit une technique permettant d'y parvenir. Il explique les étapes à suivre pour intégrer un nouveau gestionnaire Framework for Frameworks (F4F) qui sert à analyser les cadres de service Web à l'aide du scanner personnalisé WSDL (Web Service Description Language).

Ce travail est nécessaire pour que le scanner personnalisé WSDL puisse différencier les points d'entrée du service Web qui ont déjà été découverts par ce nouveau gestionnaire F4F et ceux qui existent dans le fichier WSDL. Grâce à ces informations, le scanner personnalisé WSDL va éliminer les constatations de configuration qui ont déjà été analysées par ce nouveau gestionnaire F4F.

Connexion du gestionnaire F4F de services Web au scanner personnalisé WSDL
Mappage de signature

Connexion du gestionnaire F4F de services Web au scanner personnalisé WSDL

Avant de commencer

Cette section suppose que le principal gestionnaire F4F et la génération de méthode synthétique ont déjà été développés et testés.

Procédure

Ajoutez une dépendance à partir de votre plug-in à com.ibm.appscan.frameworks.wsdl.util, qui comprend des API d'aide programmable pour signaler les services trouvés. Elle existe également dans le dossier walalib.
Dans le gestionnaire principal (qui étend la classe F4FHandler), au début de la méthode handleApp() ajoutez les lignes suivantes :
```
String filePath = WSDLReportingUtil.getServicesFilePath
     (getFrameworksInput().getFileLocs());
if (filePath!=null) {
WSDLReportingUtil.initXmlDocument(filePath);
}
```
Ces lignes créent un fichier temporaire qui sera utilisé par le scanner personnalisé WSDL.
A la fin de la méthode handleApp(), ajoutez cette ligne pour vous assurer que tous les services indiqués sont enregistrés avant que le gestionnaire F4F ne se ferme :
```
WSDLReportingUtil.saveXmlDocument();
```
Pour signaler un service, ajoutez un appel à l'une des API suivantes depuis l'API WSDLReportingUtil :
- reportService(String targetNameSpace, String serviceName, String methodSignature)
- reportService(String targetNamespace, String serviceName, String operationName, ArrayList<String> wsdlParams)
où :
- targetNameSpace est l'espace de nom cible du service. Dans JAX-WS, par exemple, il se trouve dans les annotations ou il porte le même nom que le package.
- serviceName est le nom du service. Il se trouve dans les annotations ou il porte le même nom que la classe de service.
- methodSignature est la signature de la méthode provenant du fichier WSDL, simplifiée.
- operationName est le nom de la méthode, qui est lié à un nom d'opération dans un type de port du fichier WSDL.
- wsdlParams est la liste des types de paramètre au format WSDL simple.
Actuellement, le scanner personnalisé WSDL fonctionne de façon autonome ou dans le cadre d'un examen Java/JSP. Si le nouveau gestionnaire de service Web F4F est conçu pour travailler avec un autre langage que Java™ (.NET, par exemple), assurez-vous que le scanner personnalisé WSDL est appelé à l'aide du type d'examen adéquat en procédant comme suit :
1. Accédez au répertoire <data_dir>/ltd (où <data_dir> est l’emplacement de vos données de programme AppScan Source, comme décrit dans Emplacements des fichiers de données utilisateur et des fichiers d'installation).
2. Effectuez une copie de sauvegarde de tous les fichiers, en cas de problème.
3. Ouvrez le fichier .ltd correspondant au type d'examen adéquat. Par exemple, pour C++, ouvrez le fichier cpp.ltd.
4. Ajoutez cette ligne avant la balise de fermeture <LanguageTypeDefinition> :
```
<Scanner name="wsdl"/>
```
5. Copiez la valeur file_extention_set_name, qui sera nécessaire lors de l'étape suivante.
6. Ouvrez file_extensions.xml et recherchez FileExtensionSet qui porte le nom copié lors de l'étape précédente.
7. Ajoutez la ligne suivante à cet endroit dans le fichier :
```
<FileExtension extension="wsdl" assess="true"/>
```
8. Sauvegardez tous les fichiers et redémarrez AppScan Source. Le scanner personnalisé WSDL s'exécutera désormais dans le cadre de l'examen d'application complet.

Résultats

A ce stade, le scanner personnalisé WSDL ne va afficher que les constatations de configuration (dans la vue Constatations) provenant de fichiers WSDL qui ne sont pas implémentés par votre cadre. Tous les services provenant de fichiers WSDL qui sont déjà implémentés dans l'application ne vont pas s'afficher en tant que constatation de configuration. Ils seront analysés par le nouveau gestionnaire F4F des services Web.

Mappage de signature

Pourquoi et quand exécuter cette tâche

Le scanner personnalisé WSDL va essayer de faire correspondre les méthodes signalées avec les services WSDL, les types de ports WSDL et les opérations WSDL correspondantes. C'est pourquoi les services Web sont indiqués au format WSDL. Certaines simplifications ont été ajoutées pour faciliter la compréhension de certains points :

Pour tous les types primitifs XSD, il est inutile d'ajouter l'espace de nom cible. A la place, utilisez simplement le nom (par exemple, string, int, float, double).
Pour les collections et les tableaux, [] est ajouté après le type (par exemple string[], int[]).
Pour les types de classes qui seront mappés vers des types complexes XSD (à l'aide de JAX-B ou de toute autre technologie), le type va s'afficher comme suit :
```
http//my-types/myxsdnamespace/:Customer
```
L'espace de nom doit être disponible dans l'annotation Java. S'il n'est pas disponible dans l'annotation Java, il doit correspondre à l'espace de nom du service appelant ou au nom de package, selon l'implémentation de l'infrastructure.

Remarque : les erreurs de mappage vont très probablement empêcher le scanner personnalisé WSDL de faire correspondre votre API de service Web indiqué avec l'opération WSDL associée. Si cela se produit, une constatation de configuration supplémentaire va s'afficher. Cette constatation supplémentaire sera considérée comme un faux positif et indique un problème de mappage.

Si vous ne savez pas à quoi doit ressembler la signature attendue, exécutez depuis AppScan Source un examen WSDL des fichiers WSDL eux-mêmes. Cela permet de générer des constatations pour toutes les opérations qui dépendent des services WSDL. Cliquez sur chaque constatation pour afficher la signature de la méthode dans la vue Détails des constatations.