Sécurité dans la communication à distance

Cette rubrique est spécifique à la technologie héritée assurant la compatibilité descendante avec des applications existantes et n'est pas recommandée en cas de nouveau développement. Les applications distribuées doivent maintenant être développées à l'aide de Windows Communication Foundation (WCF)

En tant que développeur d'applications .NET Remoting, vous devez disposer d'une bonne compréhension des problèmes de sécurité liés aux applications .NET Remoting, mais aussi aux applications distribuées en général. Sans une implémentation sécurisée, n'importe qui pourrait appeler une méthode sur votre objet distant ou intercepter des informations confidentielles lors de leur envoi à ou à partir d'un objet distant. Pour empêcher ceci, vous devez authentifier les clients (et éventuellement les serveurs) et chiffrer les données qu'ils échangent.

Il existe également des problèmes moins évidents. Imaginons un objet distant qui définit une méthode qui accepte un délégué en tant que paramètre. Un développeur malveillant pourrait utiliser le délégué pour forcer l'application serveur à exécuter le code de son choix. Lorsqu'un délégué encapsule une méthode statique, aucun appel sur ce délégué n'est effectué à distance, le code est appelé dans le domaine d'application qui a appelé le délégué. Par exemple, un client malveillant peut utiliser cette vulnérabilité pour appeler l'objet distant et passer un délégué qui encapsule une méthode statique. L'assembly qui implémente la méthode statique peut être copié sur le serveur et lorsque le délégué est appelé, la méthode statique est exécutée sur le serveur. Pour pallier ce problème, vous devez toujours déclarer les délégués utilisés dans les objets distants avec des types personnalisés et des paramètres que ne peuvent pas deviner les pirates. En outre, vous ne devez jamais permettre à un client de définir et de passer un type qui doit être désérialisé à votre objet distant.

Cette section décrit les diverses approches de la sécurité en fonction de certaines décisions de conception. Tous les scénarios ne sont pas évoqués ici, mais ces rubriques sont un bon point de départ.

Sécurité d'accès du code

La sécurité d'accès du code est un mécanisme qui permet de limiter l'accès du code aux ressources et aux opérations protégées. Normalement, lorsque le code essaie d'accéder à une ressource protégée, un parcours de la pile est exécuté pour garantir que toutes les frames de pile ont l'autorisation d'accéder à la ressource. Lorsqu'un appel est effectué sur un objet distant, ce parcours de la pile ne traverse pas la limite de communication à distance. Par conséquent, l'infrastructure de communication à distance requiert l'autorisation FullTrust pour s'exécuter sur le client ou le serveur. Les autorisations FullTrust désactivent les sécurités d'accès du code. Toute utilisation non autorisée d'une application de communication à distance fournit un accès non autorisé aux autorisations FullTrust.

Remarque :
Plusieurs types de systèmes étendent MarshalByRefObject, mais procèdent également à des vérifications de sécurité à l'exécution pour empêcher tout code extérieur au domaine d'application d'appeler à distance un objet de ce type. AppDomainet System.Windows.Forms.Form sont deux exemples de ces types de systèmes.

Considérations sur la sécurité dans les applications de communication à distance

Il existe généralement deux points de sécurité auxquels il convient de prêter attention dans une application distribuée : sécuriser le canal de communication et sécuriser l'application contre toute utilisation malveillante.

Pour sécuriser le canal de communication, il est nécessaire de s'assurer que les messages sont chiffrés et qu'ils ne sont pas modifiés pendant le transport. Pour sécuriser une application contre tout utilisation malveillante, il faut authentifier et autoriser les appelants. L'authentification d'un appelant consiste à vérifier qu'il est bien celui qu'il prétend être. L'autorisation d'un appelant consiste à vérifier que l'appelant a les privilèges requis pour effectuer un certain appel ou accéder à une ressource protégée.

Les canaux intégrés prennent en chargent la sécurité comme suit :

HttpChannel- Ne prend en charge l'authentification que lorsque les objets distants sont hébergés par les Services Internet (IIS). Le chiffrement est pris en charge uniquement lorsque IIS est configuré pour utiliser SSL.

TcpChannel- Prend en charge l'authentification et le chiffrement.

IpcChannel- Prend en charge l'authentification.

Remarque :
Vous devez fournir l'autorisation dans votre code. Les canaux intégrés ne peuvent pas vous la fournir, car ils ne savent pas ce que fait votre code et quelles restrictions vous avez imposées.

Attention :

Par défaut, .NET Framework Remoting ne procède ni à l'authentification ni au chiffrement. Par conséquent, il est recommandé que vous preniez toutes les mesures nécessaires à l'identification des clients et des serveurs avant d'interagir à distance avec eux. Comme les applications .NET Framework Remoting requièrent des autorisations FullTrust pour s'exécuter, un client non autorisé pourrait exécuter du code comme s'il était d'un niveau de confiance suffisant s'il se voyait accorder l'accès à votre serveur. Veillez à toujours authentifier vos clients et à chiffrer les flux de données de communication.

Voir aussi

Référence

RemotingConfiguration
ChannelServices
Context
MethodCall
RemotingServices

Concepts

Authentification avec le canal HTTP

Autres ressources

Vue d'ensemble de .NET Framework Remoting