Partager via

Considérations relatives à la sécurité XAML

  • Article

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 resxressource -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, x:Code de blocs, 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.

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 distinctes AppDomain , 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 élément spécifique XamlSchemaContext pour vos lecteurs XAML et enregistreurs d’objets XAML. Consultez 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