Exporter (0) Imprimer
Développer tout

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

Matt Powell
Microsoft Corporation

5 septembre 2001

Introduction

L'une des préoccupations majeures évoquées par les développeurs lorsque nous parlons des potentialités des Services Web est leur crainte concernant les points de vulnérabilité qui risquent de favoriser l'attaque de leurs services par des utilisateurs malveillants. Certes, ces attaques peuvent provoquer des catastrophes telles que l'indisponibilité partielle de votre service, la mise en péril de données confidentielles, ou, dans le pire des cas, la perte de contrôle de vos machines au profit de ces utilisateurs malveillants. Toutefois, il existe des protections qui permettent de limiter efficacement les risques. Nous allons passer en revue les différents types d'attaques existants et les mesures à prendre pour vous protéger dans les domaines du déploiement, de la conception et du développement. Le premier volet consacré à ce sujet va traiter des problèmes de déploiement à prendre en compte ; le volet suivant s'intéressera aux aspects de conception et de développement que vous devez connaître lors du développement de vos Services Web.

Les types d'attaques

La première étape concernant la détection des risques et la manière de les éviter consiste à comprendre les types d'attaques susceptibles de viser vos services. Une fois connus les risques encourus, il est possible de les atténuer en prenant les mesures appropriées.

Les attaques appartiennent à trois catégories principales :

  • L'usurpation d'identité
  • L'utilisation de bogues
  • Le refus de service

L'usurpation d'identité

L'une des attaques les plus courantes à l'encontre d'un système requérant l'authentification consiste, pour un pirate, à trouver les informations d'authentification d'un utilisateur, à se connecter en se faisant passer pour ce dernier et à accéder à ses informations personnelles. Ce processus est déjà très préjudiciable, mais le danger est pire encore si les informations usurpées appartiennent à un administrateur système ou à un utilisateur ayant des privilèges élevés. Dans ce cas, l'attaque risque de ne pas se limiter aux données d'un seul utilisateur, mais de compromettre celles de l'ensemble des utilisateurs.

Plusieurs approches permettent à un pirate de déterminer le mot de passe d'un utilisateur. Par exemple, il peut saisir les mots qui risquent d'avoir un sens particulier pour l'utilisateur, tels que son nom, celui de son animal de compagnie, ou la date de son anniversaire. Un pirate plus acharné peut même passer en revue tous les mots du dictionnaire (attaque de dictionnaire). Il existe d'autres moyens permettant d'obtenir les informations d'un utilisateur, notamment : surveiller les paquets réseau et lire les informations des données envoyées ; par usurpation de DNS, insérer une machine intermédiaire entre un client et le serveur dans une intention malveillante ; se présenter comme administrateur système et demander à l'utilisateur de fournir ses informations d'authentification à des fins de dépannage ; ou enregistrer un protocole de contrôle de connexion avec un serveur et en relire la séquence pour tenter d'être authentifié.

Il est possible de limiter la plupart des risques d'usurpation en prenant des mesures telles que le renforcement des mots de passe et le recours à des mécanismes d'authentification sécurisés.

L'utilisation de bogues

L'un des principaux facteurs déterminant la vulnérabilité d'un système aux attaques est la qualité du code utilisé sur ce système. Les bogues d'un système peuvent être plus nuisibles qu'un thread particulier générant une exception. Les pirates utilisent éventuellement ce type de vulnérabilité pour exécuter leur propre code sur le système et accéder aux ressources avec des privilèges élevés, ou plus simplement pour bénéficier des fuites de ressource (basées sur le bogue) qui peuvent ralentir votre système, voire le rendre indisponible. L'un des virus les plus célèbres de cette catégorie est le fameux ver Code Red, qui a utilisé un bogue dans l'extension ISAPI d'Index Server pour exécuter le code de son choix sur un système infecté, avant de rechercher d'autres machines vulnérables.

Une autre attaque courante consiste à exploiter des bogues en procédant par supposition quant à la validité des données en entrée. Imaginons un service Web XML nécessitant la saisie d'un nom d'utilisateur comme paramètre d'entrée. Si le nom de l'utilisateur n'est composé que d'une chaîne ASCII que vous placez directement dans votre requête SQL, vous augmentez la vulnérabilité de votre service. Prenons par exemple une requête SQL de votre code qui ressemble à ceci :

sqlQuery = “SELECT * FROM Users WHERE (Username=’” & UsernameInput & “’)

Si le paramètre UsernameInput contient quelque chose comme

Bob’) or not (Username=’0

votre service risque de retourner tous les enregistrements et non pas seulement celui d'un utilisateur particulier.

Le refus de service

Les attaques de refus de service ne visent pas à pénétrer dans un site, ni à en modifier les données, mais plutôt à l'asservir afin qu'il ne puisse plus répondre aux requêtes légitimes. Le virus Code Red ne s'est pas contenté d'infecter des machines puis d'en rechercher d'autres pour les infecter à leur tour, il a aussi forcé les machines infectées à expédier un grand nombre de paquets en direction du site Web officiel de la Maison Blanche. Du fait que des milliers de machines se sont trouvées infectées, le nombre de requêtes expédiées vers le site de la Maison Blanche s'est révélé extrêmement élevé. En expédiant des requêtes à partir d'un grand nombre de machines, le virus Code Red a donné lieu à ce que l'on nomme une "attaque de refus de service distribuée", qu'il est extrêmement difficile de limiter en raison du nombre même des machines impliquées.

Les requêtes de refus de service peuvent se présenter sous de multiples formes, car il existe de nombreux niveaux possibles pour expédier des requêtes simulées visant à attaquer un système. Supposons que votre site autorise les utilisateurs à exécuter la commande PING sur votre adresse IP, ce qui provoque l'envoi d'un message ICMP au serveur, puis son retour. Il s'agit d'un moyen efficace pour résoudre des problèmes de connectivité. Cependant, si des centaines de machines expédient simultanément des milliers de paquets à votre serveur, celui-ci sera trop occupé à gérer les requêtes PING pour pouvoir se consacrer aux autres requêtes valides.

L'attaque SYN se situe à un niveau légèrement plus élevé, dans lequel un programme réseau de bas niveau est écrit pour expédier ce qui apparaît comme étant le premier paquet (un paquet SYN) dans un contrôle de connexion TCP. Dans ce scénario, les dégâts sont plus importants que dans une requête PING (qu'il est possible d'ignorer si vous le décidez) : en effet, si une application écoute un port TCP (comme votre serveur Web), vous êtes vulnérable à l'extension des ressources dès que des requêtes de connexion apparemment valides se présentent.

Mais les attaques de refus de service peuvent également prendre la forme d'un envoi au service Web XML de multiples requêtes SOAP valides entraînant des recherches dans la base de données. Ces recherches peuvent prendre beaucoup de temps. Ainsi, si des milliers de requêtes semblables sont expédiés chaque seconde à votre serveur, il va en résulter une surcharge excessive tant du serveur Web qui reçoit les requêtes que du serveur de base de données principal. Là encore, votre service ne parviendra pas à gérer les autres requêtes dans un temps raisonnable.

Si votre machine comporte du code avec des bogues, les attaques de refus de service s'avèrent plus faciles encore. Par exemple, si votre service Web de production a le malheur d'afficher un message en réponse à un certain type d'erreur, un pirate va utiliser cette faille pour expédier un petit nombre de requêtes qui provoqueront l'affichage de ce message. Tous les threads gérant les requêtes risquent alors d'être verrouillés et votre service devient inaccessible.

Questions relatives au déploiement

Après avoir étudié les différentes sortes d'attaques, nous allons voir comment s'en prémunir. Il existe de nombreuses protections possibles et la plupart d'entre elles sont très simples. Commençons par examiner les types de protections qui consistent simplement à contrôler la manière dont sont configurés vos serveurs Web et vos serveurs principaux.

Plusieurs mesures de sécurité peuvent être mises en œuvre pour garantir l'invulnérabilité de vos serveurs aux attaques, la plus évidente étant de vérifier que vous disposez de la dernière mise à jour de sécurité. Vous trouverez ci-après la liste des étapes importantes à suivre pour vous protéger. Un grand nombre de ces éléments ne sont pas spécifiques à l'hébergement de services Web, mais s'appliquent également à n'importe quel serveur Web hébergeant du contenu.

Installation de la mise à jour de sécurité

Commencez par vérifier que vous disposez de la dernière mise à jour, afin de ne pas être vulnérable au virus Code Red. Vous trouverez les instructions d'installation de la mise à jour, ainsi que les liens permettant de télécharger le correctif, dans l'article Installing the patch that stops the Code Red worm Lien non MSDN France Site en anglais.

Le correctif du virus Code Red et d'autres correctifs seront fournis avec le prochain Service Pack de Microsoft® Windows® 2000 et se trouvent déjà dans Microsoft® Windows® XP.

Bien évidemment, le problème majeur est de rester invulnérable face aux autres attaques potentielles et de se protéger contre les futures agressions susceptibles de se produire. Pour plus d'informations sur les questions de sécurité et les produits Microsoft, vous pouvez vous abonner à la liste de notification de sécurité de Microsoft. Les abonnés sont avertis par courrier électronique de tout nouveau problème qui se présente. Pour connaître les instructions d'abonnement, visitez la page Product Security Notification Lien non MSDN France Site en anglais.

Limitation de l'accès à vos serveurs Web

Si vous redoutez des attaques, en particulier si des informations de votre service Web XML sont confidentielles, limitez l'accès à votre site aux seuls utilisateurs autorisés. Plusieurs manières de procéder sont possibles, mais en voici quelques-unes qui peuvent interdire aux pirates l'accès à votre service Web XML.

  1. Authentifiez les utilisateurs en mettant en place l'authentification HTTP ; limitez ensuite les ressources auxquelles ils ont accès. Pour configurer l'authentification, cliquez avec le bouton droit sur le site Web, le répertoire virtuel ou le fichier individuel du Gestionnaire de services Internet ; sélectionnez l'option Propriétés dans le menu contextuel ; ouvrez l'onglet Sécurité du répertoire et cliquez sur le bouton Modifier sous Connexions anonymes et contrôle d'authentification.
  2. Limitez les adresses IP ayant accès à votre serveur Web. Si vous avez une petite liste d'utilisateurs autorisés à utiliser votre site, vous pouvez choisir de n'autoriser l'accès qu'à leurs adresses IP particulières. Vous pouvez également limiter l'accès à certains types d'adresses IP, ou refuser l'accès à une adresse IP ou à un ensemble d'adresses IP. Vous pouvez même limiter l'accès d'après des noms de domaines, mais ceci nécessite des recherches de noms de domaines potentiellement longues sur les adresses IP qui se connectent à votre machine. Pour modifier les restrictions d'adresses IP, procédez de la façon suivante : ouvrez l'onglet Sécurité du répertoire mentionné à l'étape 1 et cliquez sur le bouton Modifier sous Restrictions par adresse IP et nom de domaine. La figure 1 montre la boîte de dialogue Restrictions par adresse IP et nom de domaine avec l'accès limité à trois adresses IP spécifiques.

Figure 1.
Figure 1. Configuration des restrictions d'adresse IP de votre site Web

  1. Exigez des connexions SSL (Secure Sockets Layer) avec des certificats client. Il s'agit sans doute du plus sûr moyen d'authentifier les utilisateurs accédant à votre site. Les restrictions SSL s'effectuent également par l'intermédiaire de l'onglet Sécurité du répertoire sous Communications sécurisées.

Configuration de votre routeur pour n'autoriser que les accès demandés

Votre routeur est votre pare-feu ; il peut bloquer la majorité des requêtes non autorisées susceptibles de vous être adressées. Les routeurs les plus courants limitent l'accès à des ports TCP spécifiques, de sorte que vous pouvez n'autoriser que des requêtes entrantes sur le port 80, qui est le port HTTP par défaut. Vous évitez ainsi que des utilisateurs se trouvant à l'extérieur du pare-feu ne tentent de se connecter à un autre service de votre machine. Soyez vigilant quant à l'ouverture des ports à d'autres services. L'ouverture d'un port s'avère pratique car elle vous permet de vous connecter à vos serveurs Web en tant que client des services Terminal Server et d'effectuer l'administration à distance ; toutefois, l'inconvénient est que n'importe qui peut tenter de se connecter à votre machine avec une connexion Terminal Server. Même si un pirate ne connaît pas le nom d'utilisateur et le mot de passe valides, il peut détourner un grand nombre de ressources de votre machine en établissant plusieurs sessions simultanément qui n'affichent que l'écran de connexion.

Les routeurs sont également des outils importants pour filtrer les paquets non autorisés qui consomment des ressources de votre machine. Naturellement, la plupart des routeurs actuels éliminent purement et simplement les paquets mal formés ; mais certains détectent aussi des éléments tels que les paquets SYN TCP qui prétendent provenir d'une adresse IP autre que celle dont ils proviennent vraiment. En activant ce type de protection, vous évitez les attaques SYN mentionnées plus haut avec les attaques de refus de service.

N'oubliez pas non plus que les restrictions par pare-feu n'ont d'incidence que sur le trafic au niveau du pare-feu. Cela peut paraître évident, mais envisagez la situation suivante : vous achetez une ligne T1 chez un fournisseur de services Internet (ISP) et vous placez un routeur sécurisé à l'extrémité de la ligne T1. Si votre fournisseur de services Internet ne sait pas détecter les requêtes SYN invalides sur ses routeurs, ceux-ci sont vulnérables aux attaques SYN et peuvent refuser le service de l'autre côté de la ligne T1 : dans ce cas, tout accès à votre site est impossible.

Dans les environnements complexes où plusieurs routeurs figurent de chaque côté d'une connexion spécifique, chacun d'eux constitue une cible potentiellement vulnérable aux attaques qui empêcheront des utilisateurs légitimes d'accéder à votre site. Pour obtenir la liste des routeurs par lesquels vos paquets devront transiter pour atteindre votre serveur, exécutez l'utilitaire TRACERT.EXE.

Configuration du filtrage TCP/IP pour limiter les ports sur lesquels les connexions sont acceptées

Si vous n'avez pas de routeur pour pare-feu ou si vous ne pouvez administrer votre routeur pour une raison quelconque, vous pouvez définir votre machine comme pare-feu en limitant le type des connexions entrantes qu'elle recevra. Dans Windows 2000, cliquez sur le bouton Démarrer, sélectionnez Paramètres, puis Connexions réseau et accès à distance, cliquez avec le bouton droit sur la carte réseau connectée à Internet et sélectionnez Propriétés. Sélectionnez Protocole Internet (TCP/IP) et cliquez sur le bouton Propriétés ; cliquez sur le bouton Avancé et ouvrez l'onglet Options. Sélectionnez Filtrage TCP/IP et cliquez sur le bouton Propriétés. Une boîte de dialogue s'affiche (Figure 2). Utilisez cette boîte pour limiter les ports sur lesquels vous recevrez les connexions. Dans l'exemple de la figure 2, l'accès est limité de telle sorte que seuls les ports 80 et 443 pour les connexions HTTP et HTTPS sont autorisés.

Figure 2.
Figure 2. Configuration du filtrage TCP/IP

Suppression des services et des logiciels inutiles

Plus le nombre de logiciels installés sur votre machine est important, plus vous êtes vulnérable aux attaques, en particulier si des services fonctionnent en tant qu'utilisateurs dotés de privilèges élevés. Si votre machine est réservée à l'exécution de votre service Web, commencez par désactiver certains autres services qui y sont proposés, notamment le service FTP, le service SMTP, ainsi que les services Windows tels que le client des services Terminal Server.

Limitez aussi le nombre de logiciels actifs ou accessibles par les services IIS (Internet Information Server). Vérifiez que seuls les sites et répertoires virtuels que vous avez configurés sont ceux dont vous avez besoin. Le site Web d'administration est probablement la première chose à supprimer. Supprimez également le répertoire virtuel IISSamples. De même, si votre machine est dédiée au fonctionnement du service Web, il est recommandé de supprimer tous les autres répertoires virtuels.

Même sur les répertoires virtuels que vous avez installés, soyez attentif quant aux types de logiciels disponibles pour effectuer des requêtes d'accès. Dans le Gestionnaire des services Internet, si vous cliquez avec le bouton droit sur un site ou un répertoire virtuel, sélectionnez Propriétés dans le menu, choisissez l'onglet Répertoire virtuel et cliquez sur le bouton Configuration. L'onglet Mappages d'application contient la liste de toutes les extensions associées aux différentes extensions ISAPI ou applications CGI. Si vous n'utilisez pas ces extensions, supprimez-les de la liste. Dans l'extension d'Index Server des fichiers .IDQ se trouvait un bogue responsable du virus Code Red. Si vous effectuez cette modification au niveau du site virtuel, vous n'avez pas à le faire pour chaque répertoire virtuel créé.

Utilisation de la liste de contrôle de sécurité de Microsoft Internet Information Server

Microsoft a créé une liste de contrôle de sécurité pour Internet Information Server 4.0 qui mentionne tous les éléments décrits ici ainsi que d'autres consignes. Vérifiez à partir de cette liste que vous avez envisagé toutes les options de sécurité. Bien que vous n'exécutiez probablement pas Internet Information Server 4.0 (la version 5.0 accompagne Windows 2000), la plupart des étapes évoquées s'appliquent et continueront de s'appliquer aux futures versions d'Internet Information Server. La liste de contrôle se trouve à l'adresse Microsoft Internet Information Server 4.0 Security Checklist Lien non MSDN France Site en anglais.

Conclusion

Il existe de nombreuses mesures, liées notamment à la configuration des machines et du réseau, qui vous permettront de protéger vos serveurs Web contre les attaques potentielles. Dans notre prochain article, nous examinerons les protections contre les attaques, en insistant sur les aspects que les développeurs et les architectes doivent prendre en considération lorsqu'ils créent des Services Web.



À votre service

Matt Powell est un membre de l'équipe des exemples d'architecture MSDN, au sein de laquelle il a contribué au développement du très innovant SOAP Toolkit 1.0. Par ailleurs, Matt Powell Matt a participé à la rédaction de l'ouvrage Running Microsoft Internet Information Server (en anglais) édité chez Microsoft Press ainsi que de nombreux articles de presse, et il se consacre chaque jour à sa très belle famille.



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



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