Liste de contrôle : sécurisation des services Web

La stratégie d'authentification a été identifiée.

Les exigences de confidentialité et d'intégrité des messages SOAP ont été prises en compte.

Les identités utilisées pour l'accès aux ressources ont été identifiées.

Les implications des niveaux de confiance de la sécurité d'accès au code ont été prises en compte.

Les entrées dans les méthodes Web sont limitées et validées en fonction du type, de la longueur, du format et de la plage.

Le nettoyage des données d'entrée est effectué uniquement en supplément de la limitation des données d'entrée.

Les données d'entrée XML sont validées en fonction d'un schéma approuvé.

Les services Web qui prennent en charge des opérations restreintes ou fournissent une authentification de la prise en charge des données sensibles.

Si des informations d'authentification en texte plein sont passées dans les en-têtes SOAP, les messages SOAP sont uniquement acheminés sur les canaux de communication cryptés, à l'aide de SSL, par exemple.

L'authentification de base est uniquement utilisée sur un canal de communication crypté.

Les mécanismes d'authentification qui utilisent des en-têtes SOAP sont basés sur la sécurité des services Web à l'aide de Web Services Enhancements (WSE).

Les services Web qui prennent en charge des opérations restreintes ou fournissent une autorisation de la prise en charge des données sensibles.

Le cas échéant, l'accès au service Web est restreint à l'aide d'une autorisation d'accès à l'URL ou d'une autorisation d'accès au fichier si l'authentification Windows est utilisée.

Le cas échéant, l'accès aux méthodes Web publiquement accessibles est restreint à l'aide des demandes d'autorisation principales déclaratives.

Les données sensibles des messages SOAP du service Web sont cryptées à l'aide du cryptage XML OU les messages sont acheminés uniquement sur les canaux de communication cryptés (à l'aide de SSL, par exemple).

Si la manipulation des paramètres est une préoccupation (en particulier lorsque les messages sont acheminés via de multiples nœuds intermédiaires à travers plusieurs liaisons réseau). Les messages sont signés numériquement pour garantir qu'ils ne seront pas trafiqués.

Une gestion des exceptions structurée est utilisée lors de la mise en œuvre des services Web.

Les détails de l'exception sont consignés dans un journal (à l'exception des données privées, telles que les mots de passe).

Les SoapExceptions sont envoyées au client à l'aide de l'élément SOAP standard <Fault> .

Si la gestion des exceptions au niveau de l'application est requise, une extension SOAP personnalisée est utilisée.

Le service Web enregistre les transactions et les opérations clés dans un journal.

La validité de l'adresse de point final est vérifiée dans Web Services Description Language (WSDL).

La propriété Comportement de l'URL de la référence Web est configurée sur dynamique pour plus de souplesse.

Les protocoles de service Web inutiles, notamment HTTP GET et HTTP POST, sont désactivés.

Le protocole de documentation est désactivé si vous ne souhaitez pas prendre en charge la génération dynamique de WSDL.

Le service Web s'exécute à l'aide du compte du processus le moins privilégié (configuré via l'élément <processModel> dans Machine.config).
Les comptes personnalisés sont cryptés à l'aide du fichier Aspnet_setref.exe.

Le suivi est désactivé avec :

<trace enabled="false" />

Le débogage de compilations est désactivé avec :

<compilation debug="false" explicit="true" defaultLanguage="vb">