Création de services Web sécurisés

  • Article

Dernière mise à jour le 31 août 2004

Sur cette page

Dans ce module Objectifs S'applique à Comment utiliser ce module Présentation Menaces et contre-mesures Problèmes de conception Validation des entrées Authentification Autorisation Données sensibles Manipulation des paramètres Gestion des exceptions Audit et journalisation Problèmes de proxy Problèmes de sécurité d'accès au code Problèmes de déploiement Résumé Informations complémentaires

Dans ce module

Le nombre d'entreprises et d'organisations qui créent et déploient des services Web est en augmentation constante. Or, en général, elles procèdent sans totalement comprendre les implications au niveau de la sécurité. Ce module explique donc comment il est possible de concevoir, de configurer et de déployer des services Web de façon sécurisée. Comme avec toute application qui accepte des requêtes externes, la validation des entrées est essentielle et plusieurs techniques sont expliquées pour garantir que seules les requêtes bien formées soient acceptées. Ce module explique également en détail les différentes méthodes d'authentification pour restreindre l'accès aux services Web aux seuls utilisateurs autorisés et permettre un audit et une journalisation de leurs actions.

Il traite aussi de Web Services Enhancements 1.0 pour Microsoft® .NET (WSE) qui prend en charge la norme WS-Security (Web Services Security) et tout un ensemble de normes nouvelles associées.

Haut de page

Objectifs

Ce module vous permettra :

  • de concevoir et déployer des services Web sécurisés ;

  • de valider les entrées vers le service Web à l'aide de paramètres fortement typés et de schémas XSD (XML Schema Definition) ;

  • d'authentifier les clients des services Web ;

  • d'autoriser l'accès à vos services Web ;

  • de protéger la confidentialité et l'intégrité des messages de vos services Web ;

  • de choisir les options de sécurité à mettre en œuvre conformément à votre scénario de déploiement (Intranet, Extranet ou Internet) ;

  • découvrir Web Services Enhancements 1.0 pour Microsoft .NET (WSE) ;

  • apprendre à utiliser la sécurité d'accès au code pour sécuriser le code des clients .NET Framework ;

  • connaître les contre-mesures à appliquer pour gérer les menaces courantes pesant sur les services Web, notamment les accès non autorisés, la manipulation des paramètres, l'écoute clandestine du réseau, la divulgation des données de configuration et la relecture des messages.

Haut de page

S'applique à

Ce module s'applique aux produits et technologies suivants :

  • Microsoft Windows® 2000 Server et Microsoft Windows Server™ 2003

  • Microsoft .NET Framework 1.1 et ASP.NET 1.1

Haut de page

Comment utiliser ce module

Pour tirer le meilleur parti de ce module :

  • **Lisez le module 19, « ** Sécurisation de votre application ASP.NET et de vos services Web ». Il s'adresse particulièrement aux administrateurs afin que ceux-ci puissent configurer une application Web ASP.NET ou un service Web en transformant une application à moitié sûre en application sécurisée.

  • Lisez le module 17, « Sécurisation de votre serveur d'applications ». Ce module vous familiarisera avec les questions relatives aux serveurs d'applications à distance.

  • Utilisez la « Liste de contrôle : sécurisation des services Web » dans la section « Listes de contrôle » de ce guide. La liste de contrôle récapitule les mesures de sécurité requises pour créer et configurer des services Web sécurisés.

  • Utilisez ce module pour bien comprendre les menaces relatives aux messages et savoir les contrer.

  • Utilisez les catégories d'application comme référence pour répondre aux problèmes courants. Les sections contiennent des informations concernant l'utilisation de ces catégories.

Haut de page

Présentation

Les services Web sont de plus en plus utilisés par les entreprises car ils permettent d'exposer aux clients et aux partenaires des produits et des services via Internet ou des extranets. Les exigences sécuritaires pour ces fournisseurs de services sont d'une importance primordiale. Dans certains cas, essentiellement dans le contexte d'intranet ou d'extranet où vous disposez d'un certain degré de contrôle sur les points finaux, les services de sécurité spécifiques de la plate-forme proposés par le système d'exploitation et par IIS (Internet Information Services) apportent des solutions de sécurité point à point. Cependant, l'architecture à base de messages propre aux services Web et les environnements hétérogènes qui couvrent des limites de confiance au sein desquelles ces services sont de plus en plus sollicités posent de nouveaux défis. Par conséquent, il est essentiel d'envisager la sécurité au niveau du message pour permettre l'interopérabilité entre les plates-formes et l'acheminement via de multiples nœuds intermédiaires.

La toute nouvelle norme WS-Security (Web Services Security) a été précisément conçue pour gérer ces problèmes. Microsoft a lancé par ailleurs Web Services Enhancements 1.0 pour Microsoft .NET (WSE), qui prend en charge WS-Security et tout un ensemble de normes nouvelles associées. WSE permet de mettre en place des solutions de sécurité au niveau des messages, y compris l'authentification, le cryptage et les signatures numériques.

Remarque : les spécifications et les normes prises en charge par WSE sont en évolution et WSE ne peut donc pas garantir la compatibilité avec les futures versions du produit. Au moment où ce document est rédigé, les tests d'interopérabilité sont en cours avec des kits d'outils non-Microsoft proposés par des fournisseurs, dont IBM et VeriSign.

Haut de page

Menaces et contre-mesures

Pour créer des services Web sécurisés, vous devez connaître les menaces associées. Les principales menaces dirigées contre les services Web sont notamment :

  • Accès non autorisé

  • Manipulation des paramètres

  • Écoute clandestine du réseau

  • Divulgation des données de configuration

  • Relecture des messages

La figure 12.1 montre les principales menaces et attaques dirigées contre des services Web.

Figure 12.1 Principales menaces contre les services Web

Accès non autorisé

Les services Web qui fournissent des informations sensibles ou restreintes doivent authentifier et autoriser les appelants. Un pirate peut exploiter un processus insuffisant d'authentification et d'autorisation pour accéder à des informations ou des opérations sensibles.

Vulnérabilités

Les vulnérabilités susceptibles de provoquer un accès non autorisé via un service Web sont notamment :

  • Absence d'authentification

  • Transmission en clair des mots de passe dans les en-têtes SOAP

  • Authentification de base utilisée sur un canal de communication non crypté

Contre-mesures

Les contre-mesures visant à éviter les accès non autorisés sont les suivantes :

  • Utiliser des Digests de mot de passe dans les en-têtes SOAP pour l'authentification.

  • Utiliser des tickets Kerberos dans les en-têtes SOAP pour l'authentification.

  • Utiliser des certificats X.509 dans les en-têtes SOAP pour l'authentification.

  • Utiliser l'authentification Windows.

  • Utiliser des autorisations basées sur les rôles pour restreindre l'accès aux services Web. Pour ce faire, vous pouvez employer l'autorisation d'URL pour contrôler l'accès au fichier du service Web (.asmx) ou au niveau de la méthode Web en utilisant des demandes d'autorisation d'entité.

Manipulation des paramètres

La manipulation des paramètres consiste à modifier, sans y être autorisé, des données envoyées entre le client du service Web et le service lui-même. Par exemple, un pirate peut intercepter un message d'un service Web lorsqu'il passe via un nœud intermédiaire en route vers sa destination, puis le modifier avant de l'envoyer à son destinataire prévu.

Vulnérabilités

Les vulnérabilités qui permettent la manipulation des paramètres sont notamment :

  • Les messages dépourvus d'une signature numérique qui les protégerait contre la falsification

  • Les messages qui ne sont pas cryptés, ce qui assurerait leur confidentialité et les protégerait contre la falsification

Contre-mesures

Les contre-mesures visant à éviter la manipulation des paramètres sont les suivantes :

  • Signez numériquement les messages. La signature numérique est utilisée au niveau du destinataire pour vérifier que le message n'a pas été falsifié durant son acheminement.

  • Cryptez la charge utile du message pour garantir sa confidentialité et éviter qu'il ne soit falsifié.

Écoute clandestine du réseau

Avec l'écoute clandestine du réseau, un pirate peut voir les messages des services Web pendant qu'ils circulent sur le réseau. Ainsi, à l'aide d'un logiciel de surveillance du réseau, il récupère des données sensibles contenues dans un message SOAP. Il peut s'agir de données sensibles propres à l'application ou d'informations d'identification.

Vulnérabilités

Les vulnérabilités qui permettent une écoute clandestine du réseau sont notamment :

  • La transmission en clair des données d'identification dans les en-têtes SOAP

  • L'absence de cryptage au niveau des messages

  • L'absence de cryptage au niveau du transport

Contre-mesures

Les contre-mesures visant à protéger les messages sensibles lorsqu'ils cheminent sur le réseau sont les suivantes :

  • Utilisez un cryptage au niveau de la couche transport, par exemple avec SSL ou IPSec. Ceci n'est applicable que si vous contrôlez les deux points terminaux.

  • Cryptez la charge utile du message pour garantir sa confidentialité. Cette technique fonctionne dans les cas où votre message traverse des nœuds intermédiaires pour aboutir à sa destination finale.

Divulgation des données de configuration

Il existe deux façons possibles de divulguer des données de configuration dans le cadre d'un service Web. Dans le premier cas, le service Web génère dynamiquement des données WSDL (Web Service Description Language) ou il les fournit dans des fichiers téléchargeables qui sont disponibles sur le serveur Web. En fonction de votre scénario, le pirate choisit ou non ce mode de divulgation.

Remarque : WSDL décrit les caractéristiques d'un service Web, par exemple les signatures de méthode et les protocoles supportés.

Dans le deuxième cas, avec une gestion des exceptions inadaptée, le service Web peut divulguer des détails stratégiques de mise en œuvre interne, utiles pour un pirate.

Vulnérabilités

Les vulnérabilités susceptibles de conduire à la divulgation de données de configuration sont notamment :

  • Des fichiers WSDL non restreints disponibles en téléchargement sur le serveur Web

  • Un service Web restreint qui prend en charge la génération dynamique du WSDL et permet à des clients non autorisés d'obtenir ses caractéristiques

  • Une mauvaise gestion des exceptions

Contre-mesures

Les contre-mesures visant à lutter contre la divulgation des données de configuration sont les suivantes :

  • Autoriser l'accès aux fichiers WSDL en utilisant des permissions NTFS.

  • Supprimer les fichiers WSDL du serveur Web.

  • Désactiver les protocoles de documentation pour éviter la génération dynamique de WSDL.

  • Capturer les exceptions et générer une SoapException ou une SoapHeaderException, qui ne renvoie au client que des informations minimales et inoffensives.

Relecture des messages

Les messages des services Web peuvent potentiellement circuler sur plusieurs serveurs intermédiaires. Dans le cas d'une attaque par relecture de message, le pirate capte et copie un message puis le « relit » au service Web en usurpant l'identité du client. Le message peut être modifié ou non.

Vulnérabilités

Les vulnérabilités susceptibles d'entraîner une relecture de message sont notamment :

  • Les messages non cryptés

  • Les messages sans signature numérique pour éviter la falsification

  • Les messages dupliqués non détectés du fait de l'absence d'un ID de message unique

Attaques

Les types les plus courants d'attaques par relecture de message sont les suivants :

  • Attaque de base par relecture. Le pirate capture et copie un message, puis il le relit et usurpe l'identité du client. Dans cette attaque, il n'a pas besoin de connaître le contenu du message.

  • Attaque du type Intrus. Le pirate capture le message puis en modifie le contenu, par exemple une adresse d'expédition, puis il le fait suivre au service Web.

Contre-mesures

Les contre-mesures permettant de lutter contre la relecture de message sont les suivantes :

  • Utilisez un canal de communication crypté, par exemple SSL.

  • Cryptez la charge utile du message pour garantir sa confidentialité et éviter qu'il ne soit falsifié. Sans empêcher les relectures de base, vous éviterez toutefois des attaques d'intrus qui modifient le contenu des messages avant de les relire.

  • Avec chaque requête, utilisez un ID de message unique ou une nonce pour détecter les doublons et signez numériquement le message de façon à éviter la falsification.

    Remarque : une nonce est une valeur obtenue par cryptographie qui identifie la requête de façon exclusive.

    Lorsque le serveur répond au client, il envoie un ID unique et signe le message, y compris l'ID. Lorsque le client émet une autre requête, il inclut l'ID avec le message. Le serveur vérifie que l'ID envoyé au client dans le message précédent figure dans la nouvelle requête provenant du client. S'il est différent, le serveur rejette la requête en supposant qu'il s'agit d'une attaque de type relecture de message.

    Le pirate ne peut pas usurper l'ID de message car ce dernier est signé. Toutefois, seul le serveur est protégé contre les attaques par relecture provenant du client via la requête ; le client de son côté ne bénéficie d'aucune protection contre les réponses transmises dans le cadre d'une attaque par relecture.

Haut de page

Problèmes de conception

Avant de commencer à développer des services Web, vous devez prendre en compte un certain nombre de points relatifs à la conception. Les principaux sont les suivants :

  • Exigences d'authentification

  • Exigences de confidentialité et d'intégrité

  • Identités des accès aux ressources

  • Sécurité d'accès au code

Exigences d'authentification

Si votre service Web propose des informations sensibles ou restreintes, il doit authentifier les appelants en vue de gérer les autorisations. Dans des environnements Windows, vous pouvez adopter l'authentification Windows. Cependant, lorsque vous n'avez pas le contrôle des deux points finaux, WSE offre des solutions d'authentification conformes à la nouvelle norme WS-Security. WSE fournit un cadre standard d'utilisation des en-têtes SOAP pour transmettre des données d'authentification qui se présentent sous la forme de noms d'utilisateur et de mots de passe, de tickets Kerberos, de certificats X.509 ou de jetons personnalisés. Pour plus d'informations, reportez-vous à la section « Authentification », plus loin dans ce module.

Exigences de confidentialité et d'intégrité

Si des données d'application stratégiques figurent dans des requêtes de service Web ou dans des réponses, étudiez le moyen d'assurer leur confidentialité et leur intégrité durant leur transit. WSE propose un contrôle d'intégrité via des signatures numériques et prend aussi en charge le cryptage XML pour crypter les éléments sensibles présents dans la charge utile du message. L'intérêt de cette approche est de s'appuyer sur la nouvelle norme WS-Security et d'offrir une solution pour les messages qui transitent par de multiples nœuds intermédiaires.

L'autre solution consiste à utiliser le cryptage au niveau transport via les canaux SSL ou IPSec. Toutefois, ces solutions ne conviennent que si vous contrôlez les deux points finaux.

Identités des accès aux ressources

Par défaut, les services Web ASP.NET n'empruntent pas d'identité et l'accès aux ressources, tant locales que distantes, s'effectue via le compte de processus ASPNET le moins privilégié. Utilisez ce compte pour accéder à des ressources réseau distantes telles que des serveurs SQL qui exigent une authentification Windows, en créant un compte local en miroir sur le serveur de base de données.

Remarque : dans Windows Server 2003, le compte appelé Service réseau sert par défaut à exécuter les services Web.

Pour plus d'informations sur l'utilisation du compte de processus ASP.NET pour l'accès à une base distante, reportez-vous à la section « Accès aux données » dans le module 19, « Sécurisation de votre application ASP.NET et de vos services Web ».

Si vous utilisez l'emprunt d'identité, les questions et aspects qui concernent les applications Web s'appliquent aussi aux services Web. Pour plus d'informations, reportez-vous aux sections « Emprunt d'identité » dans les modules 10, « Création de pages Web et de contrôles ASP.NET sécurisés et 19, « Sécurisation de votre application ASP.NET et de vos services Web ».

Sécurité d'accès au code

Considérez le niveau de confiance défini par la stratégie de sécurité au sein de votre environnement de déploiement cible. Le niveau de confiance de votre service Web, défini par la configuration de son élément <trust>, affecte les types de ressources auxquelles il a accès et les autres opérations privilégiées qu'il peut effectuer.

De plus, si vous appelez un service Web à partir d'une application Web ASP.NET, le niveau de confiance de cette application détermine la plage de services Web qu'elle peut appeler. Ainsi, une application Web configurée avec un niveau de confiance moyenne par défaut ne peut appeler des services Web que sur l'ordinateur local.

Pour plus d'informations sur l'appel de services Web à partir d'applications Web disposant d'un niveau de confiance moyenne ou partiel, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ».

Haut de page

Validation des entrées

Comme toutes les applications qui acceptent des données en entrée, les services Web doivent valider les entrées qui leur sont transmises afin de faire respecter les règles métier et d'empêcher d'éventuels problèmes de sécurité. Les méthodes Web marquées avec l'attribut WebMethod sont les points d'entrée du service Web. Les méthodes Web peuvent accepter des paramètres d'entrée plus ou moins fortement typés, qui sont souvent passés dans des chaînes. Cette approbation est habituellement déterminée par la plage et le type de clients pour lesquels le service Web est conçu.

Paramètres fortement typés

    ```
    ```
    ```
    ```

Les applications clientes qui ne sont pas basées sur .NET Framework doivent construire manuellement les entrées XML, en s'appuyant sur la définition de schéma fournie par l'organisation responsable du service Web.

L'avantage d'une forte typologie est que .NET Framework analyse les entrées et les valide en fonction de la définition du type. Cependant, à l'intérieur de la méthode Web, vous risquez d'avoir encore besoin de limiter les données d'entrée. Par exemple, même si le système de types confirme qu'il s'agit d'un objet Employee valide, vous aurez peut-être à effectuer une validation supplémentaire des champs Employee, en validant par exemple la date d'anniversaire d'un employé pour vérifier qu'il a plus de 18 ans. Peut-être devrez-vous aussi utiliser des expressions régulières pour limiter la plage des caractères utilisables dans les champs de nom, etc.

Pour plus d'informations sur la restriction des entrées, reportez-vous à la section « Validation de la saisie » dans le module 10, « Création de pages et de contrôles ASP.NET sécurisés ».

Paramètres typés souples

    ```

Données XML

Dans un scénario classique d'entreprise à entreprise, il est courant pour les clients de passer des données XML représentant des documents commerciaux tels que des bons de commande ou des factures. Les entrées doivent être validées à l'aide d'un programme par la méthode Web avant d'être traitées ou transmises aux composants en aval.

    ```
    ```
    ```

Le tableau ci-dessous montre d'autres définitions d'élément complexes utilisables dans un schéma XSD pour davantage limiter des éléments XML.

Tableau 12.1 : Exemples d'éléments de schéma XSD

Description Exemple
Utilisation d'expressions régulières pour contraindre des éléments XML 
<xsd:element name="zip">
   <xsd:simpleType>  
    <xsd:restriction base="xsd:string">  
     <xsd:pattern value="\d{5}(-\d{4})?" />  
    </xsd:restriction>  
   </xsd:simpleType>
</xsd:element>
Restriction d'une valeur décimale à deux chiffres après le séparateur décimal 
<xsd:element name="Salary">
  <xsd:simpleType>  
   <xsd:restriction base="xsd:decimal">  
    <xsd:fractionDigits value="2" />  
   </xsd:restriction>  
  </xsd:simpleType>
</xsd:element>
Restriction de la longueur d'une chaîne d'entrée 
<xsd:element name="FirstName">
 <xsd:simpleType>  
  <xsd:restriction base="xsd:string">  
   <xsd:maxLength value="50" />  
   <xsd:minLength value="2" />  
  </xsd:restriction>  
 </xsd:simpleType>
</xsd:element>
Restriction des entrées à des valeurs définies par un type énuméré 
<xsd:element name="Gender">
 <xsd:simpleType>  
   <xsd:restriction base="xsd:string">  
    <xsd:enumeration value="Male" />  
     <xsd:enumeration value="Female" />  
    </xsd:restriction>  
  </xsd:simpleType>
</xsd:element>

Pour plus d'informations, consultez les articles de la base de connaissances Microsoft suivants :

  • 307379, Procédure: Validation d'un document XML à l'aide de schémas DTD, XDR ou XSD dans Visual C# .NET

  • 318504, How To: Validate XML Fragments Against an XML Schema in Visual C#.NET

Injection SQL

L'injection SQL permet à un pirate d'exécuter des commandes arbitraires dans la base de données en utilisant la connexion de base de données du service Web. Elle pose un problème potentiel aux services Web si ceux-ci utilisent des données d'entrée pour construire des requêtes SQL. Si vos méthodes Web accèdent à la base de données, elles doivent utiliser des paramètres SQL et, dans l'idéal, des procédures stockées paramétrées. Les paramètres SQL valident le type et la longueur des entrées et ils assurent que les données sont traitées comme du texte littéral et non comme du code exécutable. Pour plus d'informations à ce sujet et sur d'autres contre-mesures visant à lutter contre l'injection SQL, reportez-vous à la section « Validation de la saisie » dans le module 14, « Création d'un accès sécurisé aux données ».

Script inter-site

Avec du script inter-site (XSS), un pirate exploite votre application de façon à exécuter un script malveillant au niveau du client. Si vous appelez un service Web depuis une application Web et renvoyez le résultat au client dans un flux de données HTML, le script inter-site est un problème potentiel. Dans ce scénario, vous devez coder les résultats envoyés par le service Web dans l'application Web avant de les retransmettre au client. Cette démarche est particulièrement importante si vous n'êtes pas propriétaire du service Web et s'il se trouve hors de la limite de confiance de l'application Web. Pour plus d'informations sur les contre-mesures relatives au script inter-site, reportez-vous à la section « Validation de la saisie » dans le module 10, « Création de pages et de contrôles ASP.NET sécurisés ».

Haut de page

Authentification

Si votre service Web propose des données sensibles ou limitées ou s'il fournit des services restreints, il doit authentifier les appelants. Il existe un certain nombre de schémas d'authentification, que l'on peut diviser en trois catégories :

  • Authentification au niveau de la plate-forme

  • Authentification au niveau du message

  • Authentification au niveau de l'application

Authentification au niveau de la plate-forme

Si vous avez le contrôle des deux points finaux et que ceux-ci se trouvent dans les mêmes domaines de confiance, vous pouvez utiliser l'authentification Windows pour authentifier les appelants.

Authentification de base

Avec ce type d'authentification, utilisez IIS pour configurer le répertoire virtuel de votre service Web. Dans ce cas, le client doit configurer le proxy et fournir des données d'identification sous la forme d'un nom d'utilisateur et d'un mot de passe. Le proxy transmet ensuite ces informations avec chaque requête adressée par son intermédiaire au service Web. Les informations d'identification sont transmises en clair et, par conséquent, vous ne devez utiliser ce type d'authentification qu'avec SSL.

    ```
Authentification Windows intégrée

Dans ce type d'authentification, vous pouvez utiliser également IIS afin de configurer le répertoire virtuel de votre service Web, ce qui donne lieu à une authentification Kerberos ou NTLM, selon l'environnement du client et du serveur. Comparée à l'authentification de base, cette méthode a pour avantage que les données d'identification ne sont pas envoyées sur le réseau, ce qui élimine la menace d'attaque par écoute clandestine.

Pour appeler un service Web configuré en vue de l'authentification Windows intégrée, le client doit explicitement configurer la propriété Credentials sur le proxy.

    ```
    ```

Si vous devez spécifier des données d'identification explicite, ne les préprogrammez pas et ne les stockez pas en texte clair. Cryptez les données d'identification de compte en utilisant DPAPI et stockez les données cryptées soit dans un élément <appSettings> du fichier Web.config, soit sous une clé de registre restreinte.

Pour plus d'informations sur l'authentification au niveau de la plate-forme, reportez-vous à la section « Sécurité de services Web » dans Modèles et pratiques Volume I, Building Secure ASP.NET Web Applications Authentication, Authorization, and Secure Communication » à l'adresse http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp?frame=true.

Authentification au niveau du message

WSE permet la mise en œuvre d'une authentification au niveau du message conforme à la nouvelle norme WS-Security. Cette solution permet de passer des jetons d'authentification de manière standard en utilisant les en-têtes SOAP.

Remarque : lorsque deux parties conviennent d'utiliser la norme WS-Security, elles doivent également se mettre d'accord sur le format précis du jeton d'authentification.

Les types suivants de jetons d'authentification sont utilisables et pris en charge par WSE :

  • Nom d'utilisateur et mot de passe

  • Ticket Kerberos

  • Certificat X.509

Nom d'utilisateur et mot de passe
    ```

Digest de nom d'utilisateur et de mot de passe

Au lieu d'envoyer un mot de passe en clair, vous pouvez transmettre un Digest. Le Digest est une valeur hachée selon l'algorithme SHA1 codée en base 64 du mot de passe codé en UTF8. Toutefois, bien que cette solution soit utilisée sur un canal sécurisé, un pirate équipé d'un logiciel de surveillance du réseau peut toujours intercepter les données et s'en servir pour obtenir un accès authentifié à votre service Web. Pour mieux contrer cette menace d'attaque par relecture de données, il est possible d'associer au Digest une nonce et un horodatage de création.

Digest de nom d'utilisateur et de mot de passe avec nonce et horodatage

    ```

Dans ce cas, le service Web doit gérer un tableau des valeurs de nonce et rejeter les messages contenant une nonce en double. Cette solution offre une meilleure protection du mot de passe et peut éviter des attaques par relecture, mais elle pose des problèmes de synchronisation d'horloge entre le client et le fournisseur lorsqu'il s'agit de calculer une heure d'expiration ; par ailleurs, elle n'empêche pas un pirate de capter un message, de modifier la nonce et de renvoyer le message au service Web. Pour contrer cette menace, il convient de signer numériquement le message. Avec WSE, vous pouvez signer un message au moyen d'un jeton personnalisé ou d'un certificat X.509. Ceci garantit une protection contre la falsification et assure l'authentification, sur la base d'une paire de clés privée/publique.

Tickets Kerberos
    ```
Certificats X.509
    ```

Pour plus d'informations sur les méthodes précédentes, consultez les exemples fournis avec WSE.

Authentification au niveau de l'application

Vous pouvez concevoir et créer votre propre système d'authentification en utilisant des en-têtes SOAP personnalisés pour votre application. Auparavant, revoyez les fonctionnalités fournies par la plate-forme et par WSE pour voir si certaines sont utilisables. Si vous devez adopter un mécanisme d'authentification personnalisé et utiliser la cryptographie, choisissez des algorithmes de cryptage standard exposés par l'espace de noms System.Security.Cryptography.

Haut de page

Autorisation

Après l'authentification, vous pouvez limiter l'accès des appelants à un sous-ensemble de fonctionnalités exposées par votre service Web, sur la base de leur identité ou de leur appartenance à un rôle. Vous avez ainsi la possibilité de réduire l'accès aux points finaux du serveur (au niveau du fichier .asmx), à des méthodes Web ou à des fonctions spécifiques au sein des méthodes Web.

Autorisation au niveau du point final du service Web

Si votre service Web est configuré pour l'authentification Windows intégrée, vous pouvez définir des autorisations NTFS sur les fichiers du service (.asmx) afin de contrôler l'accès, en fonction du contexte de sécurité de l'appelant initial. Cette autorisation est assurée par le module FileAuthorizationModule ASP.NET et l'emprunt d'identité n'est pas nécessaire.

Indépendamment du type d'authentification, vous pouvez utiliser le module UrlAuthorizationModule ASP.NET pour contrôler l'accès aux fichiers du service Web (.asmx). Vous effectuez cette configuration en ajoutant les éléments <allow> et <deny> dans l'élément <authorization> du fichier Machine.config ou Web.config.

Pour plus d'informations sur les deux formes d'autorisation, reportez-vous à la section « Autorisation » dans le module 19, « Sécurisation de votre application ASP.NET et de vos services Web ».

Autorisation au niveau de la méthode Web

    ```

Pour plus d'informations sur les demandes d'autorisation d'entité, reportez-vous à la section « Autorisation » dans le module 10, « Création de pages et de contrôles ASP.NET sécurisés ».

Autorisation par programme

    ```

Haut de page

Données sensibles

Les menaces liées à l'écoute clandestine du réseau ou à la divulgation d'informations sur des nœuds intermédiaires de l'application doivent être prises en considération si vos requêtes ou vos réponses de service Web transportent des données d'application sensibles, par exemple des numéros de carte de crédit, des données sur les employés, etc.

Dans un environnement clos où vous contrôlez les deux points finaux, vous pouvez utiliser SSL ou IPSec pour effectuer un cryptage au niveau de la couche transport. Dans d'autres environnements et lorsque les messages sont acheminés via des nœuds d'application intermédiaires, une solution au niveau du message s'impose. La norme WS-Security définit un service de confidentialité basé sur la norme de cryptage XML W3C (World Wide Web Consortium) qui permet de crypter tout ou partie d'un message SOAP avant de l'envoyer.

Cryptage XML

Vous pouvez crypter la totalité ou une partie d'un message SOAP de trois façons différentes :

  • Cryptage asymétrique en utilisant des certificats X.509

  • Cryptage symétrique en utilisant des clés partagées

  • Cryptage symétrique en utilisant des jetons binaires personnalisés

Cryptage asymétrique en utilisant des certificats X.509

Avec cette approche, le client utilise la clé publique d'un certificat X.509 pour crypter le message SOAP. Ce dernier ne peut être décrypté que par le service qui possède la clé privée correspondante.

    ```

Si vous utilisez le magasin utilisateur, vous devez charger le profil d'utilisateur du compte de processus du service Web. Si vous exécutez votre service Web en vous servant du compte local par défaut ASPNET le moins privilégié, la version 1.1 de .NET Framework charge le profil d'utilisateur de ce compte, ce qui rend le magasin utilisateur principal accessible.

Pour les services Web créés avec la version 1.1 de .NET Framework, le profil d'utilisateur ASPNET n'est pas chargé. Dans ce cas, deux options sont possibles :

  • Exécutez votre service Web en utilisant un compte personnalisé le moins privilégié possible avec lequel vous vous êtes déjà connecté interactivement au serveur Web et créez un profil utilisateur.

  • Stockez la clé dans le magasin de la machine locale et accordez l'accès au compte de processus de votre service Web. Dans Windows 2000, il s'agit du compte ASPNET par défaut. Dans Windows Serveur 2003, il s'agit du compte Service réseau par défaut.

    Pour accorder l'accès, utilisez l'Explorateur Windows afin de configurer une liste ACL sur le dossier suivant, de façon à accorder un contrôle complet au compte de processus du service Web.

    ```

Pour plus d'informations, reportez-vous à la section « Gestion des certificats X.509 », « Cryptage d'un message SOAP au moyen d'un certificat X.509 » et « Décryptage d'un message SOAP au moyen d'un certificat X.509 » dans la documentation WSE.

Cryptage symétrique en utilisant des clés partagées

Avec le cryptage symétrique, le service Web et son client partagent une clé secrète pour crypter et décrypter le message SOAP. Ce cryptage est plus rapide que le précédent, bien que le client et le fournisseur de services utilisent un mécanisme hors bande pour partager la clé.

Pour plus d'informations, reportez-vous aux sections « Cryptage d'un message SOAP au moyen d'une clé partagée » et « Décryptage d'un message SOAP au moyen au moyen d'une clé partagée » dans la documentation WSE.

Cryptage symétrique en utilisant des jetons binaires personnalisés

Vous pouvez également utiliser WSE pour définir un jeton binaire personnalisé afin d'encapsuler les données d'identification propres utilisées pour crypter et décrypter les messages. Votre code a besoin de deux classes. La classe sender (émetteur) doit être dérivée de la classe BinarySecurityToken pour encapsuler les données d'identification de sécurité personnalisées et crypter le message. La classe recipient (destinataire) doit être dérivée de la classe DecryptionkeyProvider pour récupérer la clé et décrypter le message.

Pour plus d'informations, reportez-vous aux sections « Cryptage d'un message SOAP au moyen d'un jeton de sécurité binaire personnalisé » et « Décryptage d'un message SOAP au moyen au moyen d'un jeton de sécurité binaire personnalisé » dans la documentation WSE.

Cryptage de parties de message

Par défaut, WSE crypte la totalité du corps du message SOAP mais aucune information d'en-tête. Cependant, avec WSE, il est possible de crypter et décrypter des parties d'un message, à l'aide d'un programme.

Pour plus d'informations, reportez-vous à la section « Spécification des parties d'un message SOAP qui sont signées ou cryptées » dans la documentation WSE.

Haut de page

Manipulation des paramètres

La manipulation des paramètres en rapport avec des services Web consiste pour un pirate à modifier la charge utile du message lorsque la requête ou la réponse correspondante circule entre le client et le service.

Pour contrer cette menace, vous pouvez associer une signature numérique au message SOAP afin que le destinataire ait la preuve cryptographique qu'il n'a pas été modifié depuis sa signature. Pour plus d'informations, reportez-vous à la section « Signature numérique d'un message SOAP » dans la documentation WSE.

Haut de page

Gestion des exceptions

    ```

Ces données révèlent en fait au client du service la structure de répertoire et d'autres informations qu'un pirate peut utiliser pour encombrer le chemin d'accès au répertoire virtuel et favoriser d'autres attaques.

Les services Web peuvent générer trois types d'exceptions :

  • Objets SoapException Ceux-ci sont générés par le CLR ou par le code de mise en œuvre de votre méthode Web.

  • Objets SoapHeaderException Ceux-ci sont automatiquement générés lorsque le client envoie une requête que le service ne parvient pas à traiter correctement.

  • Objets Exception Un service Web peut émettre une exception personnalisée dérivée de System.Exception. Le type d'exception précis est spécifique à la condition d'erreur. Par exemple, il peut s'agir d'un des types d'exception .NET Framework standard tels que DivideByZeroException, ArgumentOutOfRangeException ou autre.

Quel que soit le type, les données relatives à l'exception sont propagées au client à l'aide de l'élément SOAP standard <Fault>. Les clients et les services Web crées avec ASP.NET n'analysent pas directement l'élément <Fault> mais le traitent avec des objets SoapException. Ceci permet au client de configurer des blocs Try qui interceptent les objets SoapException.

Remarque : si vous générez une exception SoapException à partir d'un module HTTP personnalisé, elle n'est pas automatiquement sérialisée en tant que <Fault> SOAP. Dans ce cas, vous devez créer l'objet <Fault> SOAP manuellement.

Utilisation de SoapExceptions

    ```
    ```

Gestion des erreurs au niveau de l'application dans Global.asax

Les applications Web ASP.NET gèrent couramment des exceptions du niveau application qu'il est possible de propager au-delà d'une limite de méthode dans le gestionnaire d'événement Application_Error de Global.asax. Toutefois, cette fonctionnalité n'est pas accessible aux services Web car le gestionnaire HttpHandler de ces derniers capture l'exception avant qu'elle ne parvienne à d'autres gestionnaires.

Si vous devez gérer des exceptions au niveau de l'application, créez une extension SOAP personnalisée. Pour plus d'informations, reportez-vous à l'article MSDN, « Altering the SOAP Message using SOAP Extensions » dans la section « Building Applications » du SDK de .NET Framework, à l'adresse http://www.microsoft.com/downloads/details.aspx?FamilyID=9b3a2ca6-3647-4070-9f41-a333c6b9181d&DisplayLang=en.

Haut de page

Audit et journalisation

Avec un service Web, vous pouvez auditer et consigner les activités et les transactions en détail, soit à l'aide des fonctions spécifiques de la plate-forme, soit avec un code personnalisé inclus dans les implémentations de vos méthodes Web.

Vous pouvez développer un code qui utilise la classe System.Diagnostics.EventLog afin de consigner les actions dans le journal d'événements de Windows. Les conditions et les techniques d'autorisation pour utiliser cette classe à partir d'un service Web sont les mêmes que pour une application Web. Pour plus d'informations, reportez-vous à la section « Audit et journalisation » dans le module 10, « Création de pages et de contrôles ASP.NET sécurisés ».

Haut de page

Problèmes de proxy

Si vous utilisez WSDL pour générer automatiquement une classe proxy afin de communiquer avec un service Web, vous devez contrôler le code généré et les points finaux du service pour vous assurer d'être en relation avec le service souhaité et non avec un service usurpé. Si les fichiers WSDL installés sur le serveur distant sont mal sécurisés, un utilisateur malveillant peut les falsifier et changer les adresses des points finaux, ce qui peut avoir un impact sur le code proxy que vous générez.

En particulier, examinez l'élément <soap:address> dans le fichier .wsdl et vérifiez qu'il pointe sur l'emplacement voulu. Si vous utilisez Visual Studio .NET pour ajouter une référence Web à partir de la boîte de dialogue Ajouter une référence Web, faites défiler le contenu de la liste proposée et vérifiez les points finaux.

Enfin, que vous utilisiez Visual Studio .NET pour ajouter une référence Web ou que vous génériez le code proxy avec Wsdl.exe, inspectez attentivement le code proxy afin de détecter tout code éventuellement suspect.

Remarque : vous pouvez définir la propriété URL Behavior du proxy de service Web à Dynamic, ce qui permet de spécifier les adresses des points finaux dans le fichier Web.config.

Haut de page

Problèmes de sécurité d'accès au code

La sécurité d'accès au code peut limiter les ressources accessibles et les opérations exécutables par votre service Web. Un service Web ASP.NET est soumis à la sécurité d'accès au code ASP.NET, configuré par l'élément <trust> du service Web.

Le code du client .NET Framework qui appelle un service Web doit disposer de l'autorisation WebPermission dans le cadre de la stratégie de sécurité d'accès au code. L'état précis de WebPermission détermine la plage des services Web qu'il est possible d'appeler. Par exemple, il peut limiter votre code de telle sorte que celui-ci n'appelle que des services Web locaux ou des services installés sur un serveur donné.

Si le code du client possède une confiance totale, il bénéficie d'une autorisation WebPermission sans limite qui lui permet d'appeler n'importe quel service Web. Le code client de confiance partielle est soumis aux limitations suivantes :

  • Si vous appelez un service Web à partir d'une application Web disposant d'un niveau de confiance moyenne, vous ne pouvez accéder par défaut qu'aux services Web locaux.

  • Le code client qui utilise les classes WSE doit pouvoir bénéficier d'une plus grande confiance. Par exemple, si les classes proxy de votre service Web dérivent de Microsoft.Web.Services.WebServicesClientProtocol, fournie par WSE, la confiance totale est obligatoire. Pour utiliser WSE à partir d'une application Web avec confiance partielle, vous devez mettre en « sandbox » les appels adressés au service Web.

Pour plus d'informations sur l'appel de services Web à partir d'applications Web disposant d'un niveau de confiance partielle, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ». Pour plus d'informations sur WebPermission, reportez-vous à la section « Services Web » du module 8, « La sécurité d'accès au code en pratique ».

Haut de page

Problèmes de déploiement

Les options de sécurité disponibles dépendent considérablement des scénarios de déploiement spécifiques que vos services Web tentent de couvrir. Si vous créez des applications qui font appel à des services Web sur un réseau intranet, vous disposez d'un très grand nombre d'options et de techniques de sécurité. Si, toutefois, votre service Web est publiquement accessible sur Internet, ces options sont considérablement limitées. Cette section décrit les implications des différents scénarios de déploiement sur l'applicabilité des approches de sécurisation des services Web dont traite le début de ce module.

Déploiement sur intranet

Du fait que vous contrôlez l'application du client, le service et la plate-forme, les intranets offrent généralement la plus large gamme d'options disponibles pour sécuriser des services Web.

Dans un scénario intranet, vous pouvez habituellement choisir la totalité des options de communication et d'authentification sécurisées. Ainsi, vous pouvez choisir l'authentification Windows si le client et le service dépendent du même mécanisme ou sont dans des mêmes domaines de confiance. Vous pouvez spécifier que les développeurs d'application définissent la propriété des données d'identification selon la valeur du proxy client afin d'acheminer les données Windows de l'utilisateur au service Web.

Les communications intranet s'effectuent souvent sur un réseau privé, avec un certain niveau de sécurité. Si celui-ci est insuffisant, vous pouvez crypter le trafic à l'aide de SSL. Vous pouvez aussi mettre en œuvre une sécurité au niveau du message et installer WSE sur le client et sur le serveur afin de gérer la sécurité aux deux extrémités, de manière transparente pour l'application. WSE prend en charge l'authentification, les signatures numériques et le cryptage.

Développement sur extranet

Dans une situation d'extranet, vous risquez de devoir exposer votre service Web sur Internet à un nombre limité de partenaires. La communauté des utilisateurs reste connue, prévisible et peut éventuellement utiliser des applications clientes gérées, bien qu'elles proviennent d'environnements indépendants et distincts. Dans ce cas, vous avez besoin d'un mécanisme d'authentification adapté aux deux parties et qui ne s'appuie pas sur des domaines de confiance.

Vous pouvez utiliser l'authentification de base si vous mettez à la disposition des deux parties des informations de comptes. Avec ce type d'authentification, veillez à sécuriser les données d'identification en utilisant SSL.

Remarque : SLL protège uniquement les données d'identification sur le réseau. Il ne les protège pas si un pirate réussit à installer un outil proxy (tel que sslproxy) local par rapport à la machine du client afin d'intercepter les appels avant leur transfert au service Web via SSL.

Comme alternative, vous pouvez utiliser l'authentification par certificat client IIS au lieu de la simple transmission des données d'identification explicites. Dans ce cas, l'application appelante doit présenter un certificat valide avec l'appel. Le service Web utilise le certificat pour authentifier l'appelant et autoriser l'opération. Pour plus d'informations, reportez-vous à la section « Sécurité Extranet » dans l'article MSDN « Building Secure ASP.NET Applications » à l'adresse http://msdn.microsoft.com/library/en-us/dnnetsec/html/SecNetch06.asp.

Déploiement sur Internet

Si vous proposez votre service Web à un grand nombre de clients Internet et que vous exigiez une authentification, les options disponibles sont considérablement limitées. Les formes existantes d'authentification au niveau de la plate-forme sont probablement inadaptées, car les clients n'ont généralement pas les comptes de domaine appropriés avec lesquels ils pourraient mettre leurs données d'identification en correspondance. Le recours à l'authentification par certification client IIS et au niveau transport (SLL) est également problématique lorsqu'un grand nombre de certificats client doit se faire connaître du serveur Web IIS (ou ISA en frontal). Il reste donc comme choix possible l'autorisation et l'authentification au niveau du message et de l'application. Les données d'identification passées par le client (sous la forme du nom d'utilisateur, du mot de passe, d'un certificat, d'un ticket Kerberos ou d'un jeton personnalisé) peuvent être validées en toute transparence par l'infrastructure des services Web (WSE) ou à l'aide d'un programme à l'intérieur du service cible. Avec les certificats clients, la gestion de l'évolutivité est difficile. La gestion des clés (émission et révocation) devient un problème. Par ailleurs, l'authentification à base de certificats est consommatrice de ressources et par conséquent pose des problèmes d'évolutivité avec de nombreux clients.

SSL permet généralement de crypter le trafic du réseau (avec des certificats côté serveur uniquement), mais il est possible également de lui associer un cryptage au niveau du message.

L'utilisation de certificats clients, bien qu'avantageuse d'un point de vue sécuritaire, pose souvent problème pour un grand nombre d'utilisateurs. Vous devez soigneusement gérer les certificats et bien étudier comment les remettre aux clients, les renouveler, les révoquer, etc. Un autre problème potentiel sur Internet est l'évolutivité globale de la solution en raison de la surcharge due au traitement ou des processus de cryptage/décryptage et de validation des certificats pour un service Web à grande échelle soumis à une importante charge de travail.

Haut de page

Résumé

WS-Security est la norme en voie de développement pour la sécurité des services Web. La spécification définit des options d'authentification qui se basent sur le passage de jetons de sécurité d'une manière standard au moyen d'en-têtes SOAP. Ces jetons peuvent être des informations d'identification avec nom d'utilisateur et mot de passe, des tickets Kerberos, des certificats X.50 ou des jetons personnalisés. WS-Security prend aussi en charge les questions de confidentialité et d'intégrité des messages. Vous pouvez crypter la totalité ou une partie des messages afin qu'ils restent confidentiels, et les signer numériquement pour en assurer l'intégrité.

Dans les situations d'intranet, où vous avez le contrôle des deux points finaux, les options de sécurité au niveau de la plate-forme, telles que l'authentification Windows, sont utilisables. Pour des scénarios plus complexes dans lesquels vous ne contrôlez pas les points finaux et où les messages sont acheminés via des nœuds intermédiaires de l'application, des solutions au niveau du message sont nécessaires. La section suivante, « Informations complémentaires », répertorie les sites Web sur lesquels vous pouvez suivre les évolutions de la norme WS-Security et le kit d'outils WSE associé qui permet de créer des solutions conformes à cette norme ainsi qu'à d'autres normes nouvelles pour les services Web.

Haut de page

Informations complémentaires

Pour plus d'informations, reportez-vous aux ressources suivantes :

Haut de page