Exporter (0) Imprimer
Développer tout

Protection de votre service Web XML contre les pirates, Partie II

Matt Powell
Microsoft Corporation

Dans le précédent article, nous avons traité des différents types d'attaques et de ce qu'il est possible de mettre en place, sur le plan de la configuration, pour vous protéger. Ici, nous allons aborder plus particulièrement la prévention des attaques au niveau de la conception et du développement.

Pour commencer, je voudrais signaler l'existence de deux nouveaux outils proposés par Microsoft® pour sécuriser vos serveurs Web au maximum. IIS Lockdown Tool Lien non MSDN France Site en anglais vous aide à garantir autant que possible l'inaccessibilité des Services Internet (IIS) Microsoft® aux éventuels pirates. Cet outil de verrouillage contient une option "avancée" qui permet de sélectionner les paramètres de votre choix. Il propose aussi une option d'"annulation des modifications" au cas où les changements effectués ne correspondraient pas à votre attente. Essayez-le vite.

Le deuxième outil incontournable est Hotfix Checking Tool Lien non MSDN France Site en anglais pour IIS 5.0. Il interroge un document XML constamment mis à jour que publie Microsoft sur tous les correctifs de sécurité disponibles, puis il les compare avec ce qui est installé sur votre machine locale et vous signale les différences. Cet outil facilite la gestion des correctifs de sécurité aussi bien pour un serveur Web unique que pour un groupe important de serveurs.

Questions relatives à la conception

Lorsque vous concevez votre service Web, vous devez prendre soigneusement en considération les questions de sécurité et vos capacités à réduire les risques d'attaque. Bon nombre de facteurs susceptibles de jouer un rôle dans la prévention des attaques peuvent être examinés au moment de la conception. Dès ce moment-là en effet, vous pouvez choisir un processus d'authentification ou déterminer les types d'incident dont vous vous voulez être informé.

Détermination de vos besoins en matière de sécurité

Dès le début de la conception de votre site Web XML, vous devez déterminer le niveau de sécurité nécessaire. Certains Services Web ne nécessitent aucune authentification alors que dans d'autres, il convient d'imposer des règles strictes pour connaître avec précision les utilisateurs du service. Quel est le niveau de confidentialité des données reçues et envoyées par votre service Web XML ? Quels sont les coûts à supporter, en heures de main d'œuvre, en capacité de traitement ou en frais de contentieux si l'un de vos utilisateurs affirme ne pas avoir pu effectuer sur votre service les opérations que vous prétendez possibles ?

Examinons tout d'abord l'authentification. Certains types d'authentification sont plus vulnérables aux attaques que d'autres. Au plus bas niveau, si vous utilisez l'"authentification de base HTTP", quiconque est capable de voir les paquets circulant sur le réseau a accès à votre nom d'utilisateur et votre mot de passe. Si vous envoyez des requêtes sur Internet, vous n'avez aucun moyen de contrôler qui peut ou non voir vos données. À l'autre extrémité de l'échelle, vous pouvez envisager l'authentification avec des certificats clients SSL, ce qui permet de disposer d'un canal codé avec une quasi-invulnérabilité contre les intercepteurs de données malveillants. Pour plus de détails sur les options d'authentification, reportez-vous à l'article Authentication and Authorization Lien non MSDN France Site en anglais dans la colonne "At your service", de Mary Kirtland.

Nous avons déjà évoqué les questions de confidentialité à examiner en ce qui concerne le spoofing, ou usurpation d'identité. Vous devez également en tenir compte pour toutes les données (et pas uniquement pour les noms d'utilisateurs et les mots de passe) que vous risquez d'envoyer ou de recevoir sur votre service Web XML. Par exemple, vous pouvez établir une clé de session générée pour un utilisateur authentifié, que ce dernier enverra avec chacune des requêtes afin de les identifier. Si la clé est transmise sous forme non cryptée, un intercepteur malveillant de paquets peut la détecter, l'utiliser pour envoyer ses propres paquets à votre service Web et être donc identifié par ce dernier comme l'utilisateur légitime.

Un autre aspect de la confidentialité concerne les données élémentaires envoyées et reçues par votre service Web. Les données sont-elles stratégiques au point de nécessiter un cryptage ? L'inconvénient du cryptage SSL est qu'il pénalise les performances, puisqu'il faut crypter la totalité du canal des données envoyées ou reçues par votre service Web. Vous pouvez ne crypter que les éléments critiques figurant dans une requête, mais vous devrez alors utiliser un logiciel personnalisé sur les systèmes clients pour permettre le cryptage et le décryptage. En revanche, un avantage du SSL pour crypter un canal est que la plupart des plates-formes clientes actuelles prennent en charge les communications SSL de base, sans exiger l'écriture d'un code spécifique au niveau application.

Dans la mesure où vous envisagez une sécurité de base, vous devez aussi tenir compte du concept de répudiation, à savoir qu'une personne peut refuser de reconnaître les actions qu'elle a effectuées par le biais de votre service Web XML. Par exemple, si vous proposez un service de transactions boursières et si un utilisateur prétend ne pas avoir demandé la vente des actions que votre système a vendu pour lui, cet utilisateur répudie l'ordre de vente. Bien évidemment, ce type de problème concerne plus certains Services Web que d'autres, mais vous devez évaluer le risque lié à votre service et déterminer les mesures appropriées.

L'utilisation d'un système sécurisé pour l'authentification est certainement une première étape pour éviter ce type de risque. Ainsi, vous pouvez utiliser l'authentification HTTP de base, qui n'est pas sécurisée, mais sur un canal crypté utilisant SSL, qui lui est sécurisé. Toutefois, même si vous adoptez un système d'authentification sécurisé, il sera d'une utilité limitée si vos utilisateurs ont des mots de passe blancs ou faciles à deviner. La mise en place de mots de passe robustes est donc une autre étape importante pour éviter les types de problèmes évoqués. Ainsi, l'utilisateur et l'opérateur du service se partagent la responsabilité d'empêcher le détournement des mots de passe.

Enfin, une authentification sécurisée et des mots de passe robustes sont bien peu de choses face au risque de répudiation si vous n'assurez pas le suivi des événements se déroulant sur votre service. Chaque transaction dans laquelle il y a risque de répudiation doit être consignée dans un journal d'audit, en même temps que l'utilisateur, l'heure, la date et d'autres informations qui permettront de l'identifier. À défaut, en cas de désaccord, vous ne posséderez pas la preuve nécessaire pour appuyer la validité de vos arguments.

Audit, génération de rapports et surveillance

L'audit joue un rôle important dans la réduction des risques de répudiation ainsi que dans l'identification d'autres sortes d'attaques. Par exemple, vous risquez d'ignorer l'existence d'une attaque si vous ne disposez pas des données d'audit pour déterminer l'utilisation inhabituelle qui est faite de votre service. Ainsi, si un utilisateur malveillant lance une attaque de type dictionnaire sur votre méthode de connexion, allez-vous vous en rendre compte ? Nous allons donc examiner les points à prendre en considération en matière d'audit, de rapport et de surveillance pour protéger un service Web XML contre des attaques.

Le but de l'audit est d'enregistrer chaque élément d'information pour chaque événement qui a lieu. Toutefois, cette opération peut s'avérer fastidieuse lorsque des volumes de données importants transitent par votre service Web XML. Les enregistrements d'audit doivent inclure, au minimum, l'heure, la date et l'adresse IP de toutes les requêtes. Si vous appliquez une méthode d'authentification, vous devez inclure le nom d'utilisateur dans chaque enregistrement d'audit. Si votre service gère plusieurs méthodes ou formats de message, vous devez identifier celui ou celle qui est appelé. Enfin, vous devez inclure dans l'enregistrement suffisamment de données pour vous permettre d'identifier les détails de l'appel. Par exemple, si votre service Web XML expose une méthode, consignez tous les paramètres qui lui sont transmis.

N'oubliez pas non plus d'autres mesures, telles que la possibilité d'annuler des transactions si votre site est attaqué. Par ailleurs, vos enregistrements d'audit constituent une bonne source d'informations pour certains rapports. Et compte tenu de la taille qu'ils risquent d'atteindre, veillez à coordonner votre système d'audit avec votre stratégie de sauvegarde.

Parallèlement à l'audit qui consiste à enregistrer tous les événements survenant sur votre service, la génération de rapports a pour objectif de présenter aux utilisateurs, aux opérateurs et aux administrateurs les informations relatives à l'utilisation du système. Les rapports sont un élément essentiel dans la protection contre des attaques car ils vous permettent d'observer comment est utilisé votre service. Le rapport des erreurs qui se sont produites est par exemple d'une importance capitale, notamment les erreurs de traitement rencontrées par le service. De même, vous pouvez établir la liste des erreurs susceptibles d'indiquer une intention malveillante de la part d'un client. Si par exemple vous recevez une chaîne exceptionnellement longue dans l'un des paramètres de la requête, il faut que cette erreur soit facilement détectable. Pour des erreurs de ce type, créez des événements dans le journal des événements de l'application afin de pouvoir les contrôler de façon appropriée. Pour plus d'informations sur la consignation des événements dans le journal des événements, reportez-vous à la section Event Logging Lien non MSDN France Site en anglais dans le kit de développement de plate-forme.

L'autre type de rapport essentiel pour votre service est l'état récapitulatif de l'usage qui en est fait. Deux formes sont recommandées : premièrement, créez des rapports généraux pour votre propre analyse et qui vous permettront de détecter le niveau d'utilisation ou tout modèle d'utilisation inhabituelle. L'apparence et la présentation sont importantes car ce rapport doit vous permettre de reconnaître facilement toute anomalie. Deuxièmement, fournissez des rapports à vos utilisateurs, car ces derniers doivent également pouvoir contrôler l'utilisation du service. Une attaque sera "noyée" dans un rapport général, alors que l'utilisateur peut la détecter immédiatement sur son rapport particulier.

Il est impossible de parler des rapports sans mentionner les journaux IIS auxquels vous avez librement accès si votre service Web XML s'exécute sur Internet Information Server (IIS). Des journaux IIS sont enregistrés pour toutes les requêtes HTTP entrantes, y compris celles concernant votre service. Vous pouvez donc utiliser les informations qu'ils contiennent pour optimiser vos propres rapports.

Enfin, si vous faites l'effort de réaliser des audits et de générer les rapports adéquats, vous devez mettre en œuvre un système qui découvre les problèmes signalés. C'est là qu'intervient la surveillance.

La surveillance s'effectue à plusieurs niveaux. Bien sûr, la consultation pure et simple des rapports est un moyen de surveiller l'utilisation d'un service Web, mais vous devez également rechercher dans les journaux d'événements les erreurs éventuelles, utiliser les journaux de suivi des performances et exploiter les outils chargés de surveiller l'éventuel arrêt du serveur Web. Dans cette optique, l'Analyseur de performances va jouer un rôle déterminant. Heureusement, un grand nombre de compteurs associés à IIS fournissent des statistiques importantes pour la détection des problèmes.

Vous pouvez aussi créer vos propres compteurs de performances adaptés à votre service Web XML. Pour plus d'informations à ce sujet, reportez-vous à l'article Performance Monitoring Lien non MSDN France Site en anglais. Il est essentiel, en cas d'utilisation inhabituelle du service, que vous soyez averti d'une manière ou d'une autre. Vous pouvez utiliser les alertes de l'Analyseur de performances pour obtenir l'affichage d'un message, ou exécuter un programme si un événement anormal se déroule. La Figure 1 montre une alerte de l'Analyseur de performances qui surveille le nombre de requêtes ISAPI IIS restantes, ainsi que le nombre de requêtes ASP actuellement en attente.

Figure 1.

Figure 1. Création d'une alerte de l'Analyseur de performances

Toutefois, il ne vous servira à rien de demander audits, rapports et surveillance si vous ne pouvez rien entreprendre de concret en cas de problème. Une attaque de refus de service peut être définie pour une adresse IP spécifique, ce qui signifie que vous devez filtrer au niveau du routeur les requêtes provenant de cette adresse. Mais il est également possible qu'un refus de service ou qu'une usurpation d'identité (spoof) soient liés à un utilisateur particulier de votre service Web XML. Vous devez donc pouvoir désactiver les comptes lorsque le cas se présente. Il peut s'agir simplement de désactiver un compte utilisateur Windows dans Microsoft® Active Directory™ ou, si vous appliquez votre propre méthode d'authentification, d'ajouter dans vos enregistrements utilisateur un champ d'état indiquant si le compte est désactivé ou non. Assurez-vous aussi que les utilisateurs de votre service Web XML acceptent le document "Conditions d'utilisation" qui précisent dans quelles situations vous pouvez supprimer ou désactiver leurs comptes.

Définition de votre interface

Un des avantages des applications installées sur un serveur Web XML, par rapport aux autres applications Web, est que le schéma XML complet transmis à l'application est bien défini. Vous avez ainsi la garantie, en tant que concepteur et développeur d'application, que les données à traiter par le service Web XML sont dans un format valide. Si le format des données reçues est incorrect, les outils tels que Microsoft® SOAP Toolkit 2.0 ou .NET Framework filtrent la requête et vous ne vous occupez de rien.

Par exemple, vous n'avez pas besoin de vérifier la validité syntaxique des dates. Elles doivent déjà être en format de date XSD valide, sinon la requête est rejetée. Pour pouvoir vérifier les structures, ne masquez pas les structures à l'intérieur de variables de chaîne. Tirez parti de la puissance et de la flexibilité de XML pour décrire avec précision les données que vous envoyez et recevez.

Un serveur invisible

Lorsque des pirates cherchent à pénétrer dans votre système, la première chose qu'ils font est de chercher des informations. Ce site Web est-il hébergé sur Windows ? Ou sur un autre système ? Utilise-t-il Active Server Pages ? Index Server est-il installé ? Contient-il un composant vulnérable connu ? Contient-il une application CGI vulnérable connue ? La machine hôte exécute-t-elle Microsoft® SQL Server ? Est-il possible d'effectuer des appels DCOM (Distributed COM) sur ce serveur ?

Pour un site soucieux de se protéger, il doit être impossible de répondre à ces questions, même pour un utilisateur expérimenté d'Internet. Moins le pirate possède d'informations sur votre système et moins il peut tirer de conclusions sur votre plate-forme, plus il a des difficultés à détecter les problèmes de votre serveur.

Voyez par exemple ce qu'un pirate peut apprendre à partir d'une URL telle que "http://www.coldrooster.com/ssf/account.asp". L'extension .ASP indique que vous utilisez une machine Windows avec Active Server Pages. Aujourd'hui, les pirates ont suffisamment d'informations, grâce à leur parfaite connaissance de la configuration par défaut des Services Internet Information Server, pour détecter plusieurs points de vulnérabilité résultant d'une configuration incorrecte. Ils peuvent ainsi entrer par effraction sur votre machine à partir des hypothèses qu'ils émettent sur sa configuration.

Maintenant, que se passe-t-il si l'URL a plutôt la forme suivante : "http://www.coldrooster.com/ssf/account/" ? Dans ce cas, le pirate ne sait rien sur le système d'exploitation utilisé sur le serveur et il ne peut donc pas faire de suppositions sur sa configuration. Le mappage d'une requête au niveau du répertoire virtuel sur une page ASP est une option de configuration fréquemment employée qui peut offrir une protection non négligeable pour votre serveur.

Si vous connaissez bien le protocole HTTP de base, vous savez qu'il existe un en-tête HTTP indiquant quelle sorte de serveur Web vous utilisez. Naturellement, il s'agit là d'une technique plus complexe pour connaître votre système d'exploitation, mais il est possible également d'écrire un filtre ISAPI qui supprime ou remplace cet en-tête. Pour plus d'informations à ce sujet, reportez-vous à l'article Developing ISAPI Filters Lien non MSDN France Site en anglais et à la notification SF_NOTIFY_SEND_RESPONSE Lien non MSDN France Site en anglais dans le guide du programmeur IIS. Plus il est difficile de reconnaître le système sous-jacent sur lequel fonctionne votre serveur, plus il est improbable que le script d'un pirate cherchant à accéder via Internet à certains types de machine reconnaisse la vôtre.

Mais les systèmes d'exploitation ne sont pas les seuls points de vulnérabilité. Que se passe-t-il si la page ASP que vous avez créée exécute une requête SQL sur l'ordinateur dorsal et retourne une exception ? Renvoyez-vous l'exception au navigateur de l'utilisateur ? Celle-ci n'indique pas seulement la plate-forme du serveur Web mais également celle de la base de données. En outre, elle renseigne l'utilisateur sur la requête SQL exécutée et sur la manière dont il peut modifier les entrées du formulaire afin de récupérer des informations qui lui sont en principe interdites.

Qu'en est-il des autres exceptions COM ? Dès qu'une exception avec ses données est renvoyée à l'utilisateur, les pirates savent quels composants COM sont installés sur votre machine. Si l'objet COM est une DLL d'un fournisseur tiers, le pirate va probablement en obtenir une copie et procéder à une recherche exhaustive des points de vulnérabilité éventuels. Il acquiert ainsi un accès de très bas niveau aux problèmes susceptibles d'exister sur votre serveur.

Pareillement, le pirate peut profiter du déclenchement d'une exception COM pour tenter de bloquer votre serveur. Il sait parfaitement que la plupart des chemins d'accès des codes d'exception sont mal testés et sont souvent à l'origine d'une fuite des ressources, ou même pire. Pour éviter ce genre de situation, le code résidant sur votre serveur doit intercepter toutes les exceptions et ne renvoyer que des erreurs génériques. Dans le cas d'un service Web XML, vous devez renvoyer des erreurs SOAP qui contiennent très peu d'informations sur la plate-forme. Vous pouvez éventuellement renvoyer des données à l'utilisateur avec un ID qui permet de mettre l'erreur en correspondance avec un enregistrement du journal d'audit, mais en insérant les détails de l'erreur dans le journal d'audit et non dans l'incident SOAP renvoyé. Je conseille aux concepteurs de créer des schémas d'erreur SOAP pour leurs propres applications, avec une courte liste des options possibles, et de renvoyer uniquement une erreur de cette liste. Un client qui appelle votre service Web XML n'a pas besoin de connaître les détails d'une exception relative à une requête SQL, il lui suffit de savoir qu'une erreur SOAP côté serveur s'est produite.

Si vous utilisez Microsoft® SOAP Toolkit 2.0, vous pouvez implémenter l'interface ISoapError sur votre objet COM afin de renvoyer l'erreur SOAP de votre choix et non l'erreur générique du kit d'outils, qui fournit une masse d'informations sur les opérations réalisées par le serveur au moment où l'erreur s'est produite. Les erreurs du kit d'outils sont utiles pour le débogage lors du cycle de développement, mais elles n'ont pas à figurer sur un serveur de production. Elles peuvent en effet fournir aux pirates des informations nombreuses et potentiellement destructrices.

Un utilisateur de votre service Web XML doit connaître le format des messages SOAP envoyés et reçus par votre service, ainsi que le point de terminaison pour votre service, et c'est tout. Les autres informations ne servent qu'à renseigner les pirates sur votre système. Pour vous protéger, limitez les informations relatives à la plate-forme qui sont renvoyées et retirez de votre machine tous les éléments non indispensables, notamment les répertoires virtuels par défaut ou les mappages de script susceptibles de faciliter l'identification de votre système.

Questions relatives au développement

Pour les pirates, la vulnérabilité d'un serveur est inversement proportionnelle à la qualité du code qui s'exécute sur le serveur, plus particulièrement à la qualité du système sous-jacent (système d'exploitation, serveur Web et outils SOAP employés) ainsi que du code écrit pour l'application. Il convient d'ajouter à cette liste tout le code qui s'exécute sur le serveur, même s'il ne fait pas partie de l'application proprement dite. Toutefois, du point de vue du développeur, nous allons examiner les aspects contrôlables et ce qu'il est possible de faire pour garantir la qualité du code et éviter de fragiliser le service Web XML ou toute autre application susceptible de s'exécuter sur votre serveur.

Saturations de tampon

Les attaques les plus terribles pour un serveur sont celles qui permettent à un utilisateur distant d'exécuter un code malveillant compromettant totalement le fonctionnement du système. La plupart d'entre elles se produisent suite à des bogues de dépassement de tampon. Prenez, comme exemple caractéristique de ce type de bogue, le cas où une variable locale a été allouée dans du code C avec une longueur fixe, et où le code copie des informations issues de la requête HTTP dans cette variable. Si vous partez du principe que les données de la requête ne dépassent pas une certaine valeur arbitraire, une requête malveillante adressée à votre serveur peut entraîner le dépassement de cette valeur de sorte que les données à écrire occupent plus de place que le tampon alloué. Dans le cas d'une variable locale, le tampon est stocké dans la pile, qui contient aussi l'adresse du code vers lequel renvoyer les données une fois la fonction terminée. En saturant de données le tampon de la variable locale, les pirates peuvent écraser l'adresse de renvoi et obtenir que la fonction renvoie les adresses dont ils ont besoin, y compris l'adresse de la fonction CreateProcess de Windows. Les paramètres qui sont en général passés à la fonction CreateProcess figurent aussi dans la pile ; par conséquent, si des pirates parviennent à écrire sur la zone où se trouvent ces paramètres, ils peuvent lancer n'importe quelle application de leur choix sur le serveur.

Pour éviter ce type d'attaques, n'indiquez pas de valeur quant à la quantité de données lues par la requête et vérifiez qu'aucun bogue n'existe dans le code de manipulation du tampon. Si vous êtes programmeur en C/C++, soyez très prudent avec les fonctions suivantes : strcpy, strcat, memcpy, gets, sprintf, scanf et toutes leurs variantes (telles que lstrcpy, wcscpy, CopyMemory, etc.). N'oubliez pas que la fonction strncpy et les autres fonctions "n" sont à peine mieux, car dans ces scénarios, les variables de longueur sont souvent déterminées par programmation et elles peuvent elles aussi écraser un tampon de longueur fixe. Les paramètres de longueur dans les fonctions "n" doivent se baser sur la taille du tampon de sortie et non sur la taille de la chaîne entrante. Si vous envisagez d'utiliser ces fonctions, choisissez les versions "n" et allouez vos tampons de façon dynamique à partir du segment mémoire afin d'empêcher tout risque de dépassement de la pile. Par ailleurs, le compilateur C de Microsoft® Visual Studio® .NET prend en charge une nouvelle option /GS qui protège votre code contre de nombreux problèmes courants de dépassement de tampon.

Utilisez .NET Framework et du code géré, ce qui élimine la plupart des problèmes de saturation. Lorsque les développeurs de Microsoft ont conçu .NET Framework, ils ont compris les avantages offerts par le processus de nettoyage de la mémoire, qui élimine les problèmes provoqués par une manipulation classique des zones tampons ; c'est pourquoi ils ont prévu la possibilité d'utiliser du code géré. Vous devez toutefois rester très prudent sur l'interaction entre code géré et code non géré. Mais vous pouvez au moins, si vous le voulez, sécuriser votre application de manière appropriée.

Recherche des erreurs éventuelles

Vérifiez toujours les codes de retour pour toutes les fonctions que vous appelez. Si vous appelez une API Win32, vérifiez que l'appel s'est déroulé correctement. Si vous allouez de la mémoire, assurez-vous qu'aucune valeur NULL n'a été renvoyée. Si vous exécutez des appels COM, vérifiez qu'il n'y a pas d'exception, en particulier si vous utilisez Microsoft® Visual Basic® pour vos appels et si vous avez spécifié "On Error Resume Next". Là encore, évitez les postulats quant au résultat de ces appels.

Si vous appelez des fonctions de sécurité Win32, soyez encore plus prudent. Par exemple, en cas d'appel à ImpersonateLoggedOnUser, vérifiez impérativement que le code de retour ne contient pas d'erreur, sinon vous risquez de fournir à l'utilisateur des informations précieuses sur le contexte de sécurité. Le problème est plus préoccupant encore si vos applications sont configurées pour une exécution "In Process" sur IIS, car dans ce cas le code est éventuellement exécutable en tant que compte système local, c'est-à-dire sans quasiment aucune restriction sur la machine locale. Vous ne devez pas non plus oublier que certains appels COM inter-cloisonnés peuvent s'exécuter dans un thread disposant lui aussi de privilèges élevés.

Validation immédiate et rapide des entrées

Lorsque votre service Web XML reçoit une requête, la première chose à faire est de valider les données qui sont soumises. La validation WSDL (Web Services Description Language) par rapport au schéma en vigueur permet d'intercepter bon nombre d'erreurs, mais vous devez immédiatement effectuer les validations qui s'imposent au niveau application. Il convient notamment de détecter les caractères spéciaux, vérifier que les valeurs numériques figurent dans les intervalles adéquats, contrôler la longueur des chaînes, etc. Imaginez à priori et jusqu'à preuve du contraire que les données entrantes ne sont pas valides, même si vous pensez que toutes les requêtes proviennent d'une application spécifique. En effet, les requêtes adressées à votre service Web XML peuvent provenir de n'importe où. Si vous formulez des hypothèses concernant les données, partez du principe que celles-ci peuvent toujours être envoyées par un utilisateur malveillant.

Il est également important que le code de validation des paramètres s'exécute rapidement. Plus tôt vous reconnaissez une requête non valide, mieux c'est. Sinon, votre service Web XML risque d'être victime d'une attaque de refus de service. Il est d'autant plus facile d'empêcher vos serveurs de répondre à des requêtes légitimes qu'ils mettent du temps à traiter des requêtes illégitimes. Vous devez montrer le même souci de sécurité pour les opérations longues et consommatrices de ressources que pour des données privées. Si vous effectuez une requête SQL longue ou si une opération exige une grande puissance de traitement, assurez-vous d'abord que la demande soumise à votre service est légitime. L'utilisateur est-il valide ? L'authentification de la requête empêche non seulement les utilisateurs non autorisés d'exploiter les ressources de votre serveur, mais elle permet aussi d'enregistrer toute opération malveillante dans le journal d'audit afin que vous puissiez suivre la procédure jusqu'à un utilisateur donné. En cas de validation des entrées, validez toujours en premier les informations d'identification de l'utilisateur. Lorsque vous utilisez les mécanismes standard d'authentification HTTP, l'utilisateur est automatiquement identifié avant même que votre code soit appelé.

Fermeture des "entrées de service"

Il faut parfois, durant la phase de développement d'un projet, prévoir une "entrée de service" (backdoor) pour contourner certaines étapes du traitement sur le serveur. Par exemple, il est fréquent qu'un service Web XML génère une clé pour identifier un utilisateur sur plusieurs appels, ou de gérer un état entre ces appels. À des fins de débogage, vous pouvez juger utile d'ajouter du code pour accepter une clé entièrement constituée de uns, au lieu de mettre en place la procédure de génération d'une clé réelle. Toutefois, si vous implémentez des mécanismes de ce type pour contourner certains contrôles lors du débogage, n'oubliez pas de les supprimer avant d'activer définitivement votre service Web.

De même, évitez d'implémenter des mécanismes visant à contourner une procédure de sécurité, même s'ils vous semblent faciliter la gestion du service à long terme. Prenez le cas d'un service Web XML qui effectue une authentification au niveau application. Il est tentant d'inclure dans votre code un nom d'utilisateur secret de niveau administrateur pour permettre à ceux qui oublient leur mot de passe administrateur d'accéder malgré tout au système. Cependant, dès que le premier utilisateur utilise cette entrée de service, le secret est éventé et tous les autres utilisateurs de ce code deviennent vulnérables.

D'ailleurs, il n'est pas forcément nécessaire d'attendre la première utilisation légitime de l'entrée de service pour que le secret soit révélé. Si le compte et le mot de passe associés à cette entrée sont stockés sous la forme de chaînes dans le code, quiconque examine les fichiers binaires que vous distribuez a le moyen de voir les chaînes qui ont été définies dans votre code. Ainsi, si un pirate voit dans une DLL une chaîne du type "SecretAdministrativeUser", il va se douter qu'il s'agit d'une entrée de service insérée dans le code et il va chercher à l'exploiter.

Enfin, en ce qui concerne les entrées de service, ne cherchez pas à fournir un moyen global de rassembler l'information sur un serveur. Là encore, votre objectif est de faciliter la prise en charge du produit, mais bien souvent, il se retourne contre vous. Ne créez pas de code qui vous permette de voir ou de télécharger des fichiers de configuration ou le code source résidant sur le système. En voulant vous doter d'un instrument pratique pour analyser les dysfonctionnements d'un serveur, vous fournissez aux pirates un outil dont ils sauront eux aussi se servir. Souvent, les noms d'utilisateur et les mots de passe sont stockés dans des fichiers de configuration et les entreprises considèrent la propriété industrielle de leur code source comme leur bien le plus précieux. Quand on sait que ces options permettent souvent de visualiser les fichiers d'autres applications du serveur, le risque est encore plus grand. Ainsi, même si le code de votre service Web XML vous semble invulnérable de ce point de vue, d'autres applications du serveur peuvent l'être encore plus.

Conclusion

Des attaques contre des systèmes Web ont lieu, comme l'ont prouvé le ver Code Red et ses variantes. Heureusement, il existe des mesures qui permettent de réduire les risques auxquels votre service Web XML est confronté. Nous espérons vous avoir éclairés sur certaines vulnérabilités et sur les comportements à adopter pour y remédier et créer un service Web XML sécurisé.



Dernière mise à jour le mardi 11 décembre 2001



Pour en savoir plus
  • Protection de votre service Web XML contre les pirates, Partie I
  • Les ressources MSDN sur les Services Web
Afficher:
© 2015 Microsoft