Partager via

Divulgation d’informations

La divulgation d’informations permet à un attaquant d’obtenir des informations précieuses sur un système. Par conséquent, tenez toujours compte des informations que vous révélez et si elles peuvent, ou non, être utilisées par un utilisateur malveillant. Les éléments suivants répertorient les attaques possibles en matière de divulgation d’informations et fournissent des mesures d'atténuation pour chacune.

Sécurité des messages et HTTP

Si vous utilisez la sécurité au niveau du message sur une couche de transport HTTP, sachez que la sécurité au niveau du message ne protège pas les en-têtes HTTP. La seule façon de protéger les en-têtes HTTP consiste à utiliser le transport HTTPS au lieu de HTTP. Le transport HTTPS entraîne le chiffrement de l’intégralité du message, y compris les en-têtes HTTP, à l’aide du protocole SSL (Secure Sockets Layer).

Informations de stratégie

La sécurisation de la stratégie est importante, en particulier dans les scénarios de fédération où les exigences sensibles relatives aux jetons émis ou les informations d’émetteur de jeton sont exposées dans la stratégie. Dans ce cas, la recommandation consiste à sécuriser le point de terminaison de stratégie du service fédéré pour empêcher les attaquants d’obtenir des informations sur le service, telles que le type de revendications à placer dans le jeton émis ou rediriger les clients vers des émetteurs de jetons malveillants. Par exemple, un intrus pourrait découvrir des paires de nom d'utilisateur/mot de passe en reconfigurant la chaîne de confiance fédérée afin qu'elle se termine dans un émetteur qui exécute une attaque de « l'homme du milieu » (« man-in-the-middle »). Il est également recommandé que les clients fédérés qui obtiennent leurs liaisons grâce à la récupération de la stratégie vérifient qu'ils approuvent les émetteurs de la chaîne de confiance fédérée obtenue. Pour plus d’informations sur les scénarios de fédération, consultez Fédération.

Les images mémoire peuvent révéler des informations de revendication

Lorsqu'une application échoue, les fichiers journaux, tels que ceux produits par Dr. Watson, peuvent contenir les informations de revendication. Ces informations ne doivent pas être exportées vers d’autres entités, telles que les équipes de support technique ; sinon, les informations de revendication qui contiennent des données privées sont également exportées. Vous pouvez atténuer ce problème en n’envoyant pas les fichiers journaux à des entités inconnues.

Adresses de point de terminaison

Une adresse de point de terminaison contient les informations nécessaires pour communiquer avec un point de terminaison. La sécurité SOAP doit inclure l’adresse complète dans les messages de négociation de sécurité échangés afin de négocier une clé symétrique entre un client et un serveur. Étant donné que la négociation de sécurité est un processus de démarrage, les en-têtes d’adresse ne peuvent pas être chiffrés pendant ce processus. Par conséquent, l’adresse ne doit pas contenir de données confidentielles ; sinon, il conduit à des attaques de divulgation d’informations.

Certificats transférés non chiffrés

Lorsque vous utilisez un certificat X.509 pour authentifier un client, le certificat est transféré en clair, à l’intérieur de l’en-tête SOAP. Soyez conscient de cela comme une divulgation potentielle d’informations d’identification personnelle (PII). Ce n’est pas un problème pour le mode TransportWithMessageCredential, où l’intégralité du message est chiffrée, sécurisée au niveau du transport.

Références de service

Une référence de service est une référence à un autre service. Par exemple, un service peut transmettre une référence de service à un client au cours d’une opération. La référence de service est également utilisée avec un vérificateur d'identité de confiance, un composant interne qui garantit l’identité de l'entité cible avant de divulguer des informations telles que des données d’application ou des informations d’identification à cette cible. Si l’identité d’approbation à distance ne peut pas être vérifiée ou incorrecte, l’expéditeur doit s’assurer qu’aucune donnée n’a été divulguée qui pourrait se compromettre elle-même, l’application ou l’utilisateur.

Les atténuations sont les suivantes :

  • Les références de service sont supposées être fiables. Veillez à être prudent chaque fois que vous transférez des instances de référence de service, pour vous assurer qu'elles n'ont pas été falsifiées.

  • Certaines applications peuvent présenter une expérience utilisateur qui permet l’établissement interactif de l’approbation en fonction des données de référence du service et des données d’approbation éprouvées par l’hôte distant. WCF fournit des points d’extensibilité pour une telle installation, mais l’utilisateur doit les implémenter.

NTLM

Par défaut, dans l’environnement de domaine Windows, l’authentification Windows utilise le protocole Kerberos pour authentifier et autoriser les utilisateurs. Si le protocole Kerberos ne peut pas être utilisé pour une raison quelconque, NT LAN Manager (NTLM) est utilisé comme secours. Vous pouvez désactiver ce comportement en définissant la AllowNtlm propriété sur false. Les problèmes à prendre en compte lors de l’autorisation de NTLM sont les suivants :

  • NTLM expose le nom d’utilisateur du client. Si le nom d’utilisateur doit être conservé confidentiel, alors définissez la propriété AllowNTLM de la liaison à false.

  • NTLM ne fournit pas d’authentification serveur. Par conséquent, le client ne peut pas s’assurer qu’il communique avec le bon service lorsque vous utilisez NTLM comme protocole d’authentification.

Spécification des informations d'identification du client ou utilisation forcée de NTLM sur une identité non valide

Lors de la création d’un client, la spécification des informations d’identification du client sans nom de domaine ou la spécification d’une identité de serveur non valide entraîne l’utilisation de NTLM au lieu du protocole Kerberos (si la AllowNtlm propriété est définie truesur ). Étant donné que NTLM ne fait pas d’authentification serveur, les informations peuvent potentiellement être divulguées.

Par exemple, il est possible de spécifier les informations d’identification du client Windows sans nom de domaine, comme indiqué dans le code Visual C# suivant.

MyChannelFactory.Credentials.Windows.ClientCredential = new System.Net.NetworkCredential("username", "password");

Le code ne spécifie pas de nom de domaine et, par conséquent, NTLM sera utilisé.

Si le domaine est spécifié, mais qu’un nom de principal de service non valide est spécifié à l’aide de la fonctionnalité d’identité de point de terminaison, NTLM est utilisé. Pour plus d’informations sur la façon dont l’identité de point de terminaison est spécifiée, consultez Service Identity and Authentication.

Voir aussi