Sécurisation des pages WebPart

Article
10/22/2014

Mise à jour : novembre 2007

WebPart est la nouvelle fonctionnalité d'ASP.NET qui donne la possibilité aux utilisateurs finaux de modifier ou de personnaliser des pages Web. La personnalisation de pages Web est très pratique et puissante pour les utilisateurs d'applications Web, mais elle a également des implications en matière de sécurité dont les développeurs doivent être conscients.

Problèmes de sécurité liés à WebPart

Étant donné que WebPart est une fonctionnalité d'ASP.NET et que les contrôles WebPart sont des contrôles serveur ASP.NET étendus, les pages WebPart sont susceptibles de comporter les mêmes risques que les pages ASP.NET. Une application Web avec des pages qui utilisent des contrôles WebPart est uniquement un type spécialisé d'application ASP.NET et une application qui utilise des WebParts peut s'exécuter aux mêmes niveaux de confiance qu'une application ASP.NET ordinaire. Pour obtenir des informations générales sur la sécurité des sites Web ASP.NET, consultez Sécurisation de sites Web ASP.NET. Toutefois, WebPart présente quelques problèmes de sécurité uniques que ne connaissent pas les pages ASP.NET normales. Ces problèmes sont traités dans les sections suivantes.

Importation de données de contrôle

La fonctionnalité WebPart avec les plus grands problèmes de sécurité est la fonctionnalité d'importation. Cette fonctionnalité permet à un utilisateur d'importer un fichier de description XML qui contient l'état et les données de propriété d'un contrôle serveur (le fichier d'assembly du contrôle doit déjà être disponible sur le serveur Web). L'importation de données pour les contrôles est un moyen pour les utilisateurs de partager des données et de facilement configurer des contrôles complexes. Mais le risque inhérent est qu'il pourrait y avoir des données malveillantes dans le fichier de description. Par exemple, si quelqu'un a placé un code de script nuisible comme valeur d'une propriété de type chaîne dans le fichier de description, ce script pourrait être exécuté lorsqu'un utilisateur importe le fichier de description et ajoute le contrôle serveur référencé à une page Web. Pour réduire le risque d'importation de fichiers de description avec des données malveillantes, les contrôles serveur qui ont des propriétés de type chaîne doivent toujours coder les données de propriété. Un autre risque implique l'importation de types par le biais de fichiers de description (consultez Fichiers de description des contrôles WebPart). Un utilisateur malveillant pourrait envoyer des demandes pour charger plusieurs assemblys dans AppDomain, entraînant la consommation d'une quantité de mémoire excessive. Si vous souhaitez éviter les risques associés à l'importation, vous pouvez simplement désactiver la fonctionnalité en n'utilisant pas le contrôle serveur qui l'implémente. Ou bien, vous pouvez limiter les utilisateurs qui ont accès au contrôle. Par exemple, vous pourriez utiliser la gestion des rôles. Puis, si un utilisateur est dans le rôle d'administrateur, vous pourriez ajouter par programme ImportCatalogPart à la page pour cet utilisateur. Pour plus d'informations sur le contrôle, consultez la rubrique de référence pour la classe ImportCatalogPart.

Exportation de données de contrôle

La fonctionnalité d'exportation a presque autant de possibilité de risque que l'importation, parce qu'elle peut exposer des données sensibles. L'exportation permet aux utilisateurs d'enregistrer la propriété et les données d'état pour un contrôle particulier dans un fichier de description XML. (Il s'agit du même fichier qui peut être importé à l'aide de la fonctionnalité d'importation.) Dans ce cas, le risque principal est que les utilisateurs peuvent exporter des données sensibles hors de l'application et dans le fichier de description qui est un simple fichier texte que n'importe qui avec les autorisations appropriées peut lire. L'exportation est par défaut désactivée dans ASP.NET de sorte que, si vous n'avez pas besoin de la fonctionnalité, vous pouvez l'ignorer sans risque. C'est clairement l'option la plus sécurisée.

Si vous souhaitez activer l'exportation, vous devez connaître les options permettant de déterminer quelles propriétés peuvent être exportées. Lorsque vous créez un WebPart ou un contrôle serveur qui sera utilisé dans une zone WebPartZone, vous pouvez ajouter l'attribut de métadonnées Personalizable pour chaque propriété publique que vous souhaitez rendre exportable. Cela rend la propriété exportable si l'exportation est activée et affiche également un message à l'utilisateur, le prévenant que les données seront exportées. L'un des paramètres de l'attribut Personalizable est appelé IsSensitive. Ce paramètre de type Boolean est utile si vous souhaitez qu'une propriété soit exportable dans certaines situations, mais pas dans d'autres. Pour obtenir plus d'informations et un exemple, consultez la rubrique de référence pour la propriété ExportMode.

Présentation des détails de personnalisation

La personnalisation WebPart est la fonctionnalité qui permet aux utilisateurs de modifier des pages Web pour les adapter à leurs préférences et d'enregistrer leurs paramètres dans un stockage à long terme, afin que les pages personnalisées conservent les paramètres pour toutes les sessions de navigateur. La plupart des fonctionnalités WebPart requièrent la personnalisation ; par conséquent, elle est activée par défaut dans les sites Web ASP.NET, bien qu'elle soit uniquement utilisée sur les pages qui contiennent des contrôles WebPart. Étant donné que la personnalisation est une fonctionnalité très puissante, elle comporte également quelques risques. Les utilisateurs peuvent modifier la mise en page réelle, l'apparence et même le contenu et les contrôles sur une page Web. Les données de personnalisation sont stockées dans une base de données et sont utilisées pour restituer des pages, de sorte que les utilisateurs ont la possibilité d'effectuer de nombreuses activités malveillantes relativement au contenu d'un site. Les utilisateurs qui ont accès à la portée de personnalisation partagée peuvent même modifier la manière dont s'affichent les pages pour tous les utilisateurs.

Si vous avez une page particulière qui utilise des fonctionnalités WebPart mais qui ne requiert pas de personnalisation (par exemple, l'une des pages communes dans un site portail), c'est une méthode conseillée pour désactiver la personnalisation, parce que cela améliore les performances et réduit l'exposition de votre site aux problèmes de sécurité. Pour plus d'informations, consultez Comment : désactiver la personnalisation des WebParts.

Authentification des utilisateurs pour la personnalisation

La personnalisation requiert des utilisateurs authentifiés. Vous ne pouvez pas activer la personnalisation pour les utilisateurs anonymes. Cela signifie que pour avoir une personnalisation complète et des fonctionnalités WebPart, votre site Web doit utiliser l'authentification Windows ou l'authentification par formulaire. Pour plus d'informations sur les options d'authentification, consultez Méthodes de sécurité de base pour les applications Web ASP.NET. Pour installer un site à l'aide de la nouvelle fonctionnalité d'appartenance (qui utilise l'authentification par formulaire), consultez Gestion des utilisateurs à l'aide de l'appartenance.

Accord d'un accès minimal à la personnalisation partagée

Les modifications de personnalisation WebPart s'appliquent toujours à une plage donnée ou portée d'utilisateurs. Les modifications apportées dans la portée d'utilisateurs sont uniquement visibles à l'utilisateur qui apporte les modifications, alors que les modifications apportées dans la portée partagée sont visibles à tous les utilisateurs. La portée de personnalisation partagée existe afin que les utilisateurs ayant un rôle de gestion ou administratif puissent apporter des modifications à une page qui s'appliquent à tous les utilisateurs d'un site. Par défaut, l'accès à la portée partagée est refusé pour tous les utilisateurs. Seuls les utilisateurs sélectionnés doivent pouvoir y accéder, ce qui doit être fait explicitement dans le fichier de configuration d'un site Web. Pour plus d'informations, consultez Comment : activer la personnalisation partagée de pages WebPart.

Utilisation des contrôles testés et de confiance

Étant donné que WebPart fournit aux utilisateurs des fonctions puissantes, telles que la capacité d'ajouter de nouveaux contrôles serveur à une page, les développeurs doivent être très prudents à propos des contrôles serveur qu'ils utilisent dans une application WebPart. Les contrôles serveur, notamment ceux qui proviennent de tiers ou de vendeurs, doivent être examinés avec soin et testés pour s'assurer qu'ils peuvent être fiables pour être utilisés dans une application WebPart. Par exemple, supposons qu'un contrôle serveur particulier est mal conçu et inefficace dans son utilisation de la mémoire. Si vous ajoutez ce contrôle à un catalogue WebPart, les utilisateurs peuvent l'ajouter à une page Web. Et parce qu'un contrôle figurant dans un catalogue peut être ajouté à une page un nombre indéfini de fois (plusieurs instances), un utilisateur peut ajouter le contrôle peu performant à plusieurs reprises, ce qui peut aboutir à une attaque par déni de service lorsque la page tente de traiter les nombreuses instances du contrôle. Pour plus d'informations sur les catalogues WebParts, consultez la rubrique de référence pour la classe CatalogPart.

Utilisation d'autorisation et de filtre sur les contrôles

Les WebParts possèdent une fonction qui vous permet de définir et de vérifier le niveau d'autorisation pour les contrôles serveur utilisés dans la création de l'interface utilisateur de vos pages WebPart. Si un contrôle a l'autorisation qui respecte les critères que vous avez définis, il apparaîtra sur la page, s'il a une autorisation à un niveau plus bas ou aucune autorisation, vous pouvez modifier son apparence en conséquence ou le masquer entièrement. Par exemple, supposez qu'un de vos utilisateurs est désigné administrateur. Il peut y avoir un contrôle serveur dont vous souhaitez qu'il soit uniquement visible par l'administrateur. À l'aide des fonctionnalités d'autorisation et de filtrage de WebParts, vous pourriez vérifier que ce contrôle apparaît uniquement à un administrateur désigné, et est masqué pour les autres. Les mécanismes principaux permettant d'utiliser l'autorisation et le filtre sont la propriété AuthorizationFilter de la classe WebPart, et les méthodes IsAuthorized et OnAuthorizeWebPart de la classe WebPartManager.

Codage des propriétés de type chaîne dans les contrôles d'édition

Une fonctionnalité unique de WebParts permet aux utilisateurs finaux de faire passer une page en mode édition et de modifier un contrôle serveur en changeant sa mise en page, son apparence, son comportement et ses valeurs de propriété personnalisables. Mais cela présente un risque, car un utilisateur malveillant pourrait insérer des données incorrectes ou tenter une attaque d'injection de script à l'aide de la fonction de modification des propriétés de type chaîne. Par mesure de sécurité, si vous créez des contrôles EditorPart personnalisés pour modifier des contrôles serveur et qu'une des propriétés personnalisables dans un contrôle serveur donné est de type chaîne ou utilise un convertisseur de chaîne, votre contrôle EditorPart doit coder les données de la chaîne avant de l'assigner à la propriété. Pour obtenir un exemple, consultez la documentation de référence sur la méthode HtmlEncode.

Partager via