Sécurisation des composants du Concepteur de contrôles personnalisés
Mise à jour : novembre 2007
De nombreux contrôles serveur Web ASP.NET personnalisés possèdent des composants de concepteur correspondants qui fournissent le rendu au moment du design et les fonctionnalités de modification du contrôle. Lorsque le contrôle est en mode Design, le composant de concepteur traite les modifications des propriétés et génère le rendu du code HTML pour l'hôte de design (par exemple, Visual Studio 2005). Au moment du design, le composant de concepteur d'un contrôle personnalisé s'exécute avec le même niveau de confiance que son hôte de design. Les composants de concepteur sont en mesure d'accéder aux bases de données, de passer des appels aux sites Web hébergés sur un serveur distant, de créer et d'écrire des fichiers dans l'ordinateur du développeur, d'envoyer du courrier électronique et d'exécuter du code dans d'autres assemblys.
Les informations de cette rubrique décrivent les meilleures pratiques qui vous permettront de renforcer la sécurité des fonctionnalités du Concepteur de contrôles.
Même si l'application des meilleures pratiques en matière de codage et de configuration peut vous aider à renforcer la sécurité de votre application, il est important de tenir votre serveur d'applications à jour avec les dernières mises à jour de sécurité de Microsoft Windows et des services IIS (Internet Information Services), ainsi qu'avec tous les éventuels packages de contrôles personnalisés commerciaux installés sur votre ordinateur.
Pour plus d'informations sur les meilleures pratiques en matière d'écriture de code sécurisé et de sécurisation des applications, consultez le manuel « Writing Secure Code » de Michael Howard et David LeBlanc ou l'aide fournie par Microsoft Patterns and Practices.
Problèmes connus à signaler aux utilisateurs de contrôles personnalisés
Vous devez savoir que les contrôles personnalisés provenant de sources inconnues peuvent contenir des concepteurs qui exposent des données sensibles de votre ordinateur sur le Web ou qui exécutent du code malveillant au moment du design. Par ailleurs, vous ne pouvez pas utiliser la configuration de l'accès du code pour limiter l'accès des concepteurs de contrôles dans la mesure où ils doivent toujours s'exécuter dans l'hôte de design avec un niveau de confiance totale. Pour plus d'informations sur les niveaux de confiance, consultez Fichiers de stratégie et niveaux de confiance ASP.NET.
Problèmes connus à signaler aux développeurs de contrôles personnalisés
L'utilisation d'attributs de configuration sur des classes et des membres pour limiter les autorisations au niveau minimal requis pour les fonctionnalités du contrôle n'est pas vraiment adaptée dans le cas des composants de concepteur dans la mesure où ils doivent s'exécuter dans l'hôte de design avec un niveau de confiance totale.
Dans la mesure du possible, utilisez toujours les structures de données d'exemple pour générer des données destinées aux aperçus du contrôle au moment de l'exécution au lieu d'utiliser les données potentiellement sensibles d'une base de données.
Problèmes connus à signaler aux développeurs d'hôtes de design
Les développeurs d'hôtes de design, tels que Visual Studio 2005, doivent vérifier si le balisage HTML, le texte et d'autres données retournées par le concepteur ne présentent pas de risques pour la sécurité avant de les afficher. Par ailleurs, il faut limiter la taille des chaînes de balisage HTML et des zones du concepteur pour qu'elles conservent des dimensions acceptables. Pour plus d'informations sur la validation HTML, consultez Validation des entrées d'utilisateur dans des pages Web ASP.NET.
Voir aussi
Concepts
Introduction à la sécurité d'accès du code
Référence
Validation des entrées d'utilisateur dans des pages Web ASP.NET