Sécurisation des contrôles serveur personnalisés

Article
10/22/2014

Mise à jour : novembre 2007

Les contrôles serveur personnalisés représentent une façon d'étendre les fonctionnalités des contrôles serveur Web ASP.NET. Les consignes de sécurité de base suivantes sont fournies pour les utilisateurs et développeurs de contrôles serveur personnalisés. Pour plus d'informations sur la création de contrôles serveur personnalisés, consultez Développement de contrôles serveur ASP.NET personnalisés.

Un IDE tel que Microsoft Visual Studio 2005 simplifie l'utilisation de contrôles personnalisés aussi bien que le développement. Toutefois, les consignes de sécurité répertoriées ci-dessous s'appliquent quel que soit l'IDE utilisé.

Pour obtenir des informations d'ordre général sur la sécurité des applications Web ASP.NET, consultez Sécurité des applications Web ASP.NET.

Indications pour les utilisateurs de contrôles serveur personnalisés

Il existe de nombreuses façons d'utiliser des contrôles serveur personnalisés dans une application Web ; par exemple, vous pouvez placer des fichiers de code source directement dans le dossier App_Code de l'application Web, utiliser des contrôles du Global Assembly Cache ou utiliser les composants de communauté installés par le biais d'un programme d'installation automatisé, tel que le programme d'installation de contenu Visual Studio. Dans tous les cas, vous devez prendre des précautions contre l'importation de code nuisible ou dont l'impact peut être involontairement indésirable sur votre IDE et le serveur qui héberge les composants.

Certaines consignes de sécurité à considérer en tant qu'utilisateur de contrôles serveur personnalisés sont répertoriées ci-dessous. Cette liste n'est pas censée être complète, mais représenter un point de départ pour les recherches :

N'utilisez pas un code qui vous est inconnu ou dont vous ne maîtrisez pas les implications en matière de sécurité. Pour les composants de communauté, il est recommandé de lire les informations disponibles sur l'éditeur et de déterminer si les composants sont signés.
Envisagez non seulement la sécurité du contrôle au moment de l'exécution, mais également au moment du design. Pour plus d'informations, consultez Sécurisation des composants du Concepteur de contrôles personnalisés.
Lorsque cela est possible, utilisez des contrôles personnalisés dans les assemblys portant un nom fort et avec des éditeurs approuvés. Pour plus d'informations, consultez Comment : déterminer le nom qualifié complet d'un assembly.
Exécutez les applications Web ASP.NET qui incluent des contrôles importés dans un compte avec les privilèges les plus faibles. Pour plus d'informations sur l'exécution de processus ASP.NET avec une identité qui a des autorisations minimales, consultez Configuration de l'identité de processus ASP.NET. Dans un IDE comme Visual Studio 2005 ou Visual Web Developer Express, exécutez les applications comme un utilisateur normal et non comme un administrateur à moins de devoir exécuter des tâches d'administration.
Examinez la sécurité du système d'exploitation et les listes de contrôle d'accès Windows sur le serveur qui héberge les contrôles serveur personnalisés. Par exemple, vous devez vous assurer que le processus ASP.NET s'exécute avec une identité qui a uniquement les autorisations minimales requises pour exécuter votre application afin qu'une violation de la sécurité par un contrôle serveur personnalisé ait un impact minime sur les autres applications hébergées. Pour plus d'informations, consultez Configuration de l'identité de processus ASP.NET. En outre, examinez les autorisations des contrôles serveur personnalisés et assurez-vous qu'elles sont conformes aux autorisations de fichier et de dossier que l'identité de votre application Web ASP.NET doit avoir pour fonctionner correctement. Pour plus d'informations, consultez Listes de contrôle d'accès requis par ASP.NET.
Utilisez la sécurité d'accès du code pour restreindre les ressources auxquelles l'application Web (avec les contrôles serveur personnalisés) peut accéder et les opérations privilégiées qu'elle peut exécuter. Pour plus d'informations, consultez Sécurité d'accès du code ASP.NET.
Utilisez l'outil .NET Framework Configuration tool (Mscorcfg.msc) pour gérer et configurer des assemblys dans le Global Assembly Cache et ajuster la stratégie de sécurité d'accès du code. Dans la mesure où Mscorcfg.msc est conçu pour aider les administrateurs avancés à effectuer des tâches relatives à la configuration d'applications, collaborez avec votre administrateur système pour déterminer si son utilisation est appropriée dans votre cas. Pour plus d'informations, consultez Outil .NET Framework Configuration (Mscorcfg.msc).

Indications pour les développeurs de contrôles serveur personnalisés

En tant que développeur de contrôles personnalisés, vous devez suivre les méthodes conseillées d'ordre général pour la sécurité dans les contrôles et pages d'application ASP.NET ainsi que dans le .NET Framework. Dans de nombreux cas, les utilisateurs de vos contrôles serveur personnalisés peuvent ne pas connaître l'ensemble des détails d'implémentation ni implications en matière de sécurité. Vous devez envisager ce cas de figure en suivant les conventions de sécurité établies et en appelant clairement toutes les autorisations nécessaires au fonctionnement de vos composants. Vous pouvez démarrer vos recherches de problèmes de sécurité d'ordre général et de leurs solutions pour les applications Web à l'aide du Sécurisation de sites Web ASP.NETGuide du développeur .NET Framework Concepts fondamentaux sur la sécurité et des rubriques relatives à la sécurité sur le site Web (en anglais) Patterns and Practices.

Après avoir conçu et implémenté vos contrôles serveur Web personnalisés, vous devez décider du mode de remise des composants aux utilisateurs. Deux méthodes courantes de remise sont sous forme d'assembly ou de composant de communauté. Si vous remettez vos composants sous forme d'assembly, vous devez signer votre assembly (opération connue également sous le nom de signature avec un nom fort). La signature confère à votre assembly une identité unique que d'autres logiciels peuvent utiliser pour l'identifier et y faire explicitement référence. Il existe également d'autres avantages, comme détaillé dans Programmation à l'aide d'assemblys.

Si vous remettez vos composants sous forme de composant de communauté avec une procédure d'installation automatisée, vous devez signer vos composants par chiffrement. La signature permet de vérifier que les données proviennent d'une partie spécifique en créant une signature numérique propre à cette partie. Une façon de créer des composants de communauté à utiliser avec Visual Studio 2005 consiste à employer le programme d'installation de contenu Visual Studio et à créer des fichiers .vsi qui peuvent être signés.

Certaines consignes de sécurité à considérer lorsque vous développez des composants de contrôles serveur personnalisés sont répertoriées ci-dessous. Cette liste n'est pas censée être complète, mais représenter un point de départ pour les recherches :

Fournissez des instructions avec vos contrôles serveur personnalisés sur leur utilisation ainsi que les attentes en matière de ressources et d'autorisations nécessaires à un fonctionnement correct.
Signez numériquement vos composants. Si vous empaquetez votre contrôle personnalisé comme un assembly, signez l'assembly avec un nom fort. Pour plus d'informations, consultez Création et utilisation d'assemblys avec nom fort. Si vous utilisez un programme d'installation automatisé, tel que le programme d'installation de contenu Visual Studio, vous devez toujours signer vos composants.
Suivez les méthodes conseillées pour la gestion des exceptions dans votre code. Pour plus d'informations, consultez la page (en anglais) Chapter 10 sur le site Web Patterns and Practices, par exemple.
Si vous envisagez que des développeurs de pages ajoutent vos contrôles personnalisés à la boîte à outils du concepteur visuel, les fassent glisser sur l'aire de conception et accèdent à leurs propriétés et événements dans l'Explorateur de propriétés, vous devez considérer la sécurité au moment du design en plus de la sécurité au moment de l'exécution. Pour plus d'informations, consultez Sécurisation des composants du Concepteur de contrôles personnalisés.
Tenez compte des principales menaces relatives aux contrôles et pages d'application Web, y compris l'injection de code, la divulgation d'informations, l'infiltration de session, l'usurpation d'identité, la manipulation de paramètres et l'espionnage réseau. À cette fin, effectuez une analyse de modélisation des menaces de vos composants avant le déploiement. Pour plus d'informations, consultez la rubrique (en anglais) Threat Modeling Web Applications sur le site Web Patterns and Practices.