Considérations relatives à la sécurité XAML

Cet article décrit les meilleures pratiques en matière de sécurité dans les applications lorsque vous utilisez l’API XAML et .NET XAML Services.

XAML non approuvé dans les applications

Dans le sens le plus général, le code XAML non approuvé est une source XAML que votre application n’a pas spécifiquement inclus ou émis.

XAML compilé dans ou stocké en tant que ressource resx-type au sein d’un assembly approuvé et signé n’est pas intrinsèquement non approuvé. Vous pouvez approuver le code XAML autant que vous approuvez l’assembly dans son ensemble. Dans la plupart des cas, vous êtes uniquement préoccupé par les aspects de confiance de XAML libre, qui est une source XAML que vous chargez à partir d’un flux ou d’autres E/S. Le xaml libre n’est pas un composant ou une fonctionnalité spécifique d’un modèle d’application avec une infrastructure de déploiement et d’empaquetage. Toutefois, un assembly peut implémenter un comportement qui implique le chargement de XAML libre.

Pour le code XAML non approuvé, vous devez généralement le traiter comme s’il s’agissait d’un code non approuvé. Utilisez le bac à sable (sandbox) ou d’autres métaphores pour empêcher le code XAML non approuvé d’accéder à votre code approuvé.

La nature des fonctionnalités XAML donne au CODE XAML le droit de construire des objets et de définir leurs propriétés. Ces fonctionnalités incluent également l’accès aux convertisseurs de types, le mappage et l’accès aux assemblys dans le domaine d’application, à l’aide d’extensions de balisage, de blocs x:Code, et ainsi de suite.

En plus de ses fonctionnalités au niveau du langage, XAML est utilisé pour la définition de l’interface utilisateur dans de nombreuses technologies. Le chargement d’un code XAML non approuvé peut signifier le chargement d’une interface utilisateur d’usurpation d’identité malveillante.

Important

Il n’existe aucun moyen pris en charge de charger en toute sécurité un code XAML entièrement non approuvé dans le processus. Les API de chargement XAML, telles que Load et Parse, instancient des types arbitraires et définissent leurs propriétés, ce qui équivaut à exécuter du code arbitraire. L’application, et non l’analyseur, possède la décision d’approbation concernant le balisage qu’elle charge. Si le balisage peut être influencé par un attaquant, isolez la charge dans une limite à privilège faible, telle qu’un processus ou un bac à sable distinct, et ne vous fiez pas à l’analyseur pour le rendre sûr.

Formulaires compilés et binaires de XAML

Certaines technologies compilent du code XAML dans un formulaire binaire ou tokenisé chargé au moment de l’exécution. Une forme binaire de XAML a les mêmes fonctionnalités de construction d’objet que le code XAML de texte équivalent, ce qui lui permet de prendre en compte les mêmes considérations de confiance. Traitez une source XAML binaire comme fiable uniquement lorsqu’elle provient d’un assembly ou d’une ressource compilé, signé ou généré. Ne chargez pas de source XAML binaire provenant d’un flux, d’un fichier ou d’un document non approuvé, et sachez qu’un format de conteneur peut incorporer du contenu tel que l’un de ses composants.

Les lecteurs restrictifs sont une mesure de renforcement, pas un bac à sable

Un chemin de chargement peut offrir un lecteur restrictif ou de liste verte qui bloque un ensemble de types dangereux connus. Ce type de lecteur est une étape de renforcement de la défense en profondeur utile, mais ce n’est pas un bac à sable de sécurité. Un lecteur restrictif peut toujours autoriser de nombreux types intégrés, y compris les types qui ont des effets secondaires tels que l’accès aux ressources réseau. Ne traitez pas une analyse restrictive du balisage non approuvé comme sécurisée. Continuez à isoler les marques non approuvées dans une limite à privilèges faibles.

Note

Les frameworks individuels s’appuient sur .NET services XAML et ajoutent leurs propres chargeurs, formats XAML binaires et conteneurs de documents. Pour obtenir des conseils spécifiques à l’infrastructure sur le chargement du balisage non approuvé dans Windows Presentation Foundation (WPF), consultez Sécurité (WPF).

Partage de contexte entre lecteurs et écrivains

L’architecture des services XAML .NET pour les lecteurs XAML et les enregistreurs XAML nécessite souvent de partager un lecteur XAML vers un enregistreur XAML ou un contexte de schéma XAML partagé. Le partage d’objets ou de contextes peut être nécessaire si vous écrivez une logique de boucle de nœud XAML ou si vous fournissez un chemin d’enregistrement personnalisé. Ne partagez pas les instances de lecteur XAML, le contexte de schéma XAML non définie ou les paramètres des classes de lecteur/enregistreur XAML entre du code approuvé et non approuvé.

La plupart des scénarios et opérations impliquant l’écriture d’objets XAML pour un stockage de type CLR peuvent simplement utiliser le contexte de schéma XAML par défaut. Le contexte de schéma XAML par défaut n’inclut pas explicitement les paramètres susceptibles de compromettre la confiance totale. Il est donc sûr de partager le contexte entre les composants de lecteur/enregistreur XAML approuvés et non approuvés. Toutefois, si vous effectuez cette opération, il est toujours recommandé de conserver ces lecteurs et enregistreurs dans des étendues AppDomain distinctes, avec l’un d’entre eux spécifiquement prévu/bac à sable pour une confiance partielle.

Espaces de noms XAML et approbation d’assembly

La syntaxe et la définition non qualifiées de base pour la façon dont XAML interprète un mappage d’espace de noms XAML personnalisé sur un assembly ne fait pas la distinction entre un assembly approuvé et non approuvé tel qu’il est chargé dans le domaine d’application. Ainsi, il est techniquement possible pour un assembly non approuvé d’usurper le mappage d’espace de noms XAML prévu d’un assembly approuvé et capturer les informations d’objet et de propriété déclarées d’une source XAML. Si vous avez des exigences de sécurité pour éviter cette situation, votre mappage d’espace de noms XAML prévu doit être effectué à l’aide de l’une des techniques suivantes :

  • Utilisez un nom d’assembly complet avec un nom fort dans tout mappage d’espace de noms XAML effectué par le code XAML de votre application.

  • Limitez le mappage d’assembly à un ensemble fixe d’assemblys de référence, en construisant un XamlSchemaContext spécifique pour vos lecteurs XAML et enregistreurs d’objets XAML. Voir XamlSchemaContext(IEnumerable<Assembly>).

Mappage de type XAML et accès système de type

XAML prend en charge son propre système de type, qui de nombreuses façons est un homologue de la façon dont CLR implémente le système de type CLR de base. Toutefois, pour certains aspects de la sensibilisation au type où vous prenez des décisions d’approbation sur un type en fonction de ses informations de type, vous devez différer les informations de type dans les types de stockage CLR. Cela est dû au fait que certaines des fonctionnalités de création de rapports spécifiques du système de type XAML sont laissées ouvertes en tant que méthodes virtuelles et ne sont donc pas entièrement sous le contrôle des implémentations des services XAML .NET d’origine. Ces points d’extensibilité existent, car le système de type XAML est extensible, pour correspondre à l’extensibilité du code XAML lui-même et à ses stratégies de mappage de types possibles par rapport à l’implémentation par défaut soutenue par CLR et au contexte de schéma XAML par défaut. Pour plus d’informations, consultez les notes spécifiques sur plusieurs propriétés de XamlType et XamlMember.

Voir aussi

  • Last updated on