Sécurité (WPF)

Lors du développement d'applications hébergées par le navigateur et autonomes Windows Presentation Foundation (WPF), vous devez considérer le modèle de sécurité. Les applications autonomes WPF s'exécutent avec des autorisations illimitées (jeu d'autorisations CASFullTrust), qu'elles soient déployées à l'aide de Windows Installer (.msi), XCopy ou ClickOnce. Le déploiement d'applications WPF de confiance partielle, autonomes, avec ClickOnce n'est pas pris en charge. Toutefois, une application hôte de confiance totale peut créer un AppDomain de confiance partielle à l'aide du modèle de complément .NET Framework. Pour plus d'informations, consultez Vue d'ensemble des compléments WPF.

Les applications hébergées par un navigateur WPF sont hébergées par Windows Internet Explorer ou Firefox et peuvent être des XAML browser applications (XBAPs) ou des documents Extensible Application Markup Language (XAML) libre. Pour plus d'informations, consultez Vue d'ensemble des applications de navigateur XAML.

Les applications hébergées par un navigateur WPF s'exécutent par défaut dans un bac à sable (sandbox) de sécurité de confiance partielle, qui est limité au jeu d'autorisations de la zone Internet CAS par défaut. Cela permet d'isoler efficacement les applications hébergées par un navigateur WPF de l'ordinateur client, de la même façon que pour des applications Web typiques. Une XBAP peut élever des privilèges, jusqu'à la confiance totale, selon la zone de sécurité de l'URL de déploiement et la configuration de la sécurité du client. Pour plus d'informations, consultez Sécurité de confiance partielle de WPF.

Cette rubrique décrit le modèle de sécurité des applications Windows Presentation Foundation (WPF) autonomes et hébergées par un navigateur.

Cette rubrique contient les sections suivantes :

• Navigation sécurisée

• Paramètres de sécurité du logiciel de navigation Web

• Contrôle WebBrowser et contrôles de fonctionnalités

• Désactivation des assemblys APTCA pour les applications clientes d'un niveau de confiance partiel

• Comportement de bac à sable (sandbox) pour les fichiers XAML libre

• Ressources pour le développement des applications WPF qui encouragent la sécurité

Navigation sécurisée

Pour XBAPs, WPF distingue deux types de portées de navigation : l'application et le navigateur.

La navigation dans l'application est la navigation entre des éléments de contenu dans une application hébergée par un navigateur. La navigation dans un navigateur est la navigation qui modifie le contenu et l'URL d'emplacement d'un navigateur lui-même. La relation entre la navigation dans l'application (en général XAML) et la navigation dans le navigateur (en général HTML) est affichée dans l'illustration suivante :

Le type de contenu considéré comme sécurisé pour la navigation à partir d'une application XBAP dépend essentiellement du fait qu'il s'agisse d'une navigation dans une application ou dans un navigateur.

Sécurité de la navigation dans une application

La navigation dans une application est considérée comme sécurisée si elle peut être identifiée avec un URI à en-tête pack, qui prend en charge quatre types de contenu :

Remarque
Pour plus d'informations sur les fichiers de données d'application et les URIs à en-tête pack, consultez Fichiers de ressources, de contenu et de données d'une application WPF.

La navigation vers ces fichiers ayant ces types de contenu est possible via l'utilisateur ou par programmation :

• Navigation utilisateur. L'utilisateur navigue en cliquant sur un élément Hyperlink.

• Navigation par programmation. L'application navigue sans impliquer l'utilisateur, par exemple, en définissant la propriété NavigationWindow.Source.

Sécurité de la navigation dans un navigateur

La navigation dans un navigateur est considérée comme sécurisée uniquement si les conditions suivantes sont respectées :

• Navigation utilisateur. L'utilisateur navigue en cliquant sur un élément Hyperlink qui est dans la NavigationWindow principale, et non dans un Frame imbriqué.

• Zone. Le contenu sur lequel porte la navigation se situe sur Internet ou un intranet local.

• Protocole. Le protocole utilisé est http, https, file ou mailto.

Si une application XBAP tente d'accéder au contenu sans respecter ces conditions, une exception SecurityException est levée.

Paramètres de sécurité du logiciel de navigation Web

Les paramètres de sécurité sur votre ordinateur déterminent l'accès accordé à tout logiciel de navigation Web. Le logiciel de navigation Web inclut toute application ou composant qui utilise le WinINet (page éventuellement en anglais) ou les API UrlMon (page éventuellement en anglais), notamment Internet Explorer et PresentationHost.exe.

Internet Explorer est doté d'un mécanisme qui vous permet de configurer la fonctionnalité que vous pouvez exécuter dans ou à partir de Internet Explorer, notamment :

• Composants appartenant au .NET Framework

• Contrôles et plug-ins ActiveX

• Téléchargements

• Scripts

• Authentification utilisateur

La collection de fonctionnalités pouvant être sécurisée de cette façon est configurée pour chacune des zones suivantes : Internet, Intranet, Sites de confiance et Sites sensibles. Les étapes suivantes décrivent comment configurer vos paramètres de sécurité :

1. Ouvrez le Panneau de configuration.

2. Cliquez sur Réseau et Internet puis sur Options Internet.

   La boîte de dialogue Options Internet apparaît.

3. Sous l'onglet Sécurité, sélectionnez la zone pour laquelle les paramètres de sécurité seront configurés.

4. Cliquez sur le bouton Personnaliser le niveau.

   La boîte de dialogue Paramètres de sécurité s'ouvre et vous pouvez configurer les paramètres de sécurité pour la zone sélectionnée.

   

Remarque
Vous pouvez également arriver à la boîte de dialogue Options Internet à partir d'Internet Explorer.Cliquez sur Outils, puis sur Options Internet.

À partir de Windows Internet Explorer 7, les paramètres de sécurité suivants sont inclus spécifiquement pour .NET Framework :

• XAML libre. Détermine si Internet Explorer peut accéder aux fichiers XAML et les libérer (options Activer, Désactiver et Demander).

• Applications du navigateur XAML. Détermine si Internet Explorer peut accéder aux fichiers XBAPs et les exécuter (options Activer, Désactiver et Demander).

Par défaut, ces paramètres sont tous activés pour les zones Internet, Intranet local et Sites de confiance et désactivés pour la zone Sites sensibles.

Paramètres du Registre WPF relatifs à la sécurité

Outre les paramètres de sécurité disponibles via les Options Internet, les valeurs de Registre suivantes sont disponibles pour le blocage sélectif de plusieurs fonctionnalités WPF sensibles à la sécurité. Les valeurs sont définies sous la clé suivante :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\Windows Presentation Foundation\Features

Le tableau suivant décrit les différentes valeurs pouvant être utilisées.

Contrôle WebBrowser et contrôles de fonctionnalités

Le contrôle WebBrowser WPF peut être utilisé pour héberger le contenu Web. Le contrôle WebBrowser WPF encapsule le contrôle ActiveX WebBrowser sous-jacent. WPF fournit de la prise en charge pour la sécurisation de votre application lorsque vous utilisez le contrôle WebBrowser WPF pour héberger le contenu Web non fiable. Toutefois, certaines fonctionnalités de sécurité doivent être directement appliquées par les applications à l'aide du contrôle WebBrowser. Pour plus d'informations sur le contrôle ActiveX WebBrowser, consultez Vues d'ensemble et didacticiels du contrôle WebBrowser (page éventuellement en anglais).

Remarque
Cette section s'applique également au contrôle Frame puisqu'il utilise le WebBrowser pour naviguer jusqu'au contenu HTML.

Si le contrôle WPF WebBrowser est utilisé pour héberger le contenu Web non fiable, votre application doit utiliser un AppDomain de confiance partielle pour permettre d'isoler votre code d'application du code de script HTML potentiellement nuisible. Cela se vérifie tout particulièrement si votre application interagit avec le script hébergé à l'aide de la méthode InvokeScript et de la propriété ObjectForScripting. Pour plus d'informations, consultez Vue d'ensemble des compléments WPF.

Si votre application utilise le contrôle WebBrowser WPF, une autre méthode pour augmenter la sécurité et atténuer les attaques consiste à activer des contrôles de fonctionnalités Internet Explorer. Les contrôles de fonctionnalités sont des ajouts à Internet Explorer qui permettent aux administrateurs et aux développeurs de configurer des fonctionnalités d'Internet Explorer et des applications qui hébergent le contrôle ActiveX WebBrowser, encapsulé par le contrôle WebBrowser WPF. Les contrôles de fonctionnalités peuvent être configurés à l'aide de la fonction CoInternetSetFeatureEnabled (page éventuellement en anglais) ou en modifiant les valeurs dans le Registre. Pour plus d'informations sur les contrôles de fonctionnalités, consultez Introduction aux contrôles de fonctionnalités (page éventuellement en anglais) et Contrôles de fonctionnalités Internet (page éventuellement en anglais).

Si vous développez une application WPF autonome qui utilise le contrôle WebBrowser WPF, WPF active automatiquement les contrôles de fonctionnalités suivants pour votre application.

Puisque ces contrôles de fonctionnalités sont activés de manière non conditionnelle, ils peuvent affaiblir une application de confiance totale. Dans ce cas, s'il n'existe aucun risque pour la sécurité de l'application spécifique et le contenu hébergé, le contrôle de fonctionnalité correspondant peut être désactivé.

Les contrôles de fonctionnalités sont appliqués par le processus qui instancie l'objet ActiveX WebBrowser. Par conséquent, si vous créez une application autonome qui peut naviguer jusqu'à du contenu non fiable, vous devez sérieusement envisager d'activer des contrôles de fonctionnalités supplémentaires.

Remarque
Cette recommandation est basée sur les recommandations générales pour la sécurité hôte de MSHTML et SHDOCVW.Pour plus d'informations, consultez FAQ sur la sécurité hôte de MSHTML : partie I sur II (page éventuellement en anglais) et FAQ sur la sécurité hôte de MSHTML : partie II sur II (page éventuellement en anglais).

Pour votre fichier exécutable, envisagez d'activer les contrôles de fonctionnalités suivants en affectant 1 à la valeur de Registre.

Pour votre fichier exécutable, envisagez de désactiver le contrôle de fonctionnalité suivant en affectant 0 à la valeur de Registre.

Si vous exécutez une XAML browser application (XBAP) de confiance partielle qui inclut un contrôle WebBrowser WPF dans Windows Internet Explorer, WPF héberge le contrôle ActiveX WebBrowser dans l'espace d'adressage du processus Internet Explorer. Puisque le contrôle ActiveX WebBrowser est hébergé dans le processus Internet Explorer, tous les contrôles de fonctionnalités pour Internet Explorer sont également activés pour le contrôle ActiveX WebBrowser.

Les XBAP qui fonctionnent dans Internet Explorer obtiennent également un niveau supplémentaire de sécurité en comparaison aux applications autonomes normales. Cette sécurité supplémentaire est due au fait qu'Internet Explorer, et par conséquent le contrôle ActiveX WebBrowser, s'exécute en mode protégé par défaut sur Windows Vista et Windows 7. Pour plus d'informations sur le mode protégé, consultez Connaissance et utilisation d'Internet Explorer en mode protégé (page éventuellement en anglais).

Remarque
Si vous essayez d'exécuter une XBAP qui inclut un contrôle WebBrowser WPF dans Firefox tout en étant dans la zone Internet, une SecurityException sera levée.Cela est dû à la stratégie de sécurité de WPF.

Désactivation des assemblys APTCA pour les applications clientes d'un niveau de confiance partiel

Lorsque des assemblys managés sont installés dans le global assembly cache (GAC), ils sont tous d'un niveau de confiance suffisant puisque l'utilisateur doit fournir une autorisation pour les installer. Comme ils ont un niveau de confiance suffisant, seules les applications clientes parfaitement fiables peuvent utiliser ces assemblys. Pour autoriser les applications d'un niveau de confiance partiel à utiliser ces assemblys, ils doivent porter l'attribut AllowPartiallyTrustedCallersAttribute (APTCA). Seuls les assemblys dont l'exécution dans des situations d'un niveau de confiance partiel a été testée doivent être marqués avec cet attribut.

Toutefois, il est possible qu'un assembly APTCA présente un défaut de sécurité après avoir été installé dans le GAC. Lorsqu'un défaut de sécurité est détecté, les éditeurs de l'assembly peuvent fournir une mise à jour de sécurité pour résoudre le problème sur les installations existantes et pour protéger les installations réalisées après la détection du problème. L'une des options de la mise à jour consiste à désinstaller l'assembly, bien que cela risque de bloquer d'autres applications clientes parfaitement fiables qui utilisent l'assembly.

WPF possède un mécanisme grâce auquel un assembly APTCA peut être désactivé pour les XBAPs d'un niveau de confiance partiel, sans désinstaller l'assembly APTCA.

Pour désactiver un assembly APTCA, vous devez créer une clé de Registre spéciale :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\APTCA\<AssemblyFullName>, FileVersion=<AssemblyFileVersion>

Voici un exemple :

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\policy\APTCA\aptcagac, Version=1.0.0.0, Culture=neutral, PublicKeyToken=215e3ac809a0fea7, FileVersion=1.0.0.0

Cette clé établit une entrée pour l'assembly APTCA. Vous devez créer également une valeur dans cette clé qui active ou désactive l'assembly. Les détails de cette valeur sont les suivants :

• Nom de la valeur : APTCA_FLAG.

• Type valeur : REG_DWORD.

• Données de la valeur : 1 pour désactiver ; 0 pour activer.

Si un assembly doit être désactivé pour les applications clientes d'un niveau de confiance partiel, vous pouvez écrire une mise à jour qui crée la clé de Registre et la valeur.

Remarque
Les principaux assemblys .NET Framework ne sont pas affectés par cette méthode de désactivation, puisqu'ils sont requis pour l'exécution des applications managées.Le support technique pour la désactivation des assemblys APTCA cible essentiellement les applications tierces.

Comportement de bac à sable (sandbox) pour les fichiers XAML libre

Les fichiers XAML libre sont des fichiers XAML de balisage uniquement qui ne dépendent pas d'un quelconque code-behind, gestionnaire d'événements ou assembly spécifique à l'application. Lorsque le navigateur accède directement à des fichiers XAML libre, ces derniers sont chargés dans un bac à sable (sandbox) de sécurité par le jeu d'autorisations par défaut de la zone Internet.

Cependant, le comportement de sécurité est différent lorsqu'un NavigationWindow ou un Frame dans une application autonome accède à ces fichiers XAML libres.

Dans les deux cas, le fichier XAML libre hérite des autorisations de son application hôte. Du point de vue de la sécurité, ce comportement peut toutefois être indésirable, en particulier si le fichier XAML libre a été généré par une entité inconnue ou non fiable. Ce type de contenu est considéré comme du contenu externe et vous pouvez configurer Frame et NavigationWindow pour qu'ils l'isolent. Pour procéder à cet isolement, la propriété SandboxExternalContent doit avoir la valeur true, comme indiqué dans les exemples suivants pour Frame et NavigationWindow :

<Frame 
  Source="ExternalContentPage.xaml" 
  SandboxExternalContent="True">
</Frame>

<!-- Sandboxing external content using NavigationWindow-->
<NavigationWindow 
  xmlns="https://schemas.microsoft.com/winfx/2006/xaml/presentation" 
  Source="ExternalContentPage.xaml" 
  SandboxExternalContent="True">
</NavigationWindow>

Lorsque ce paramètre est sélectionné, le contenu externe sera chargé dans un processus distinct de celui qui héberge l'application. Ce processus est limité au jeu d'autorisations par défaut de la zone Internet, ce qui permet un isolement efficace de l'application d'hébergement et de l'ordinateur client.

Remarque

Bien que la navigation des fichiers XAML libres d'une NavigationWindow ou d'un Frame dans une application autonome soit implémentée selon le navigateur WPF qui héberge l'infrastructure, impliquant le processus PresentationHost, le niveau de sécurité est légèrement inférieur au niveau du contenu chargé directement dans Internet Explorer sur Windows Vista et Windows 7 (lequel serait encore via PresentationHost). Cela est dû au fait qu'une application WPF autonome utilisant un navigateur Web ne fournit pas la fonctionnalité de sécurité du mode protégé supplémentaire d'Internet Explorer.

Ressources pour le développement des applications WPF qui encouragent la sécurité

Les quelques ressources supplémentaires suivantes fournissent de l'aide pour le développement des applications WPF qui encouragent la sécurité :

Voir aussi

Concepts

Sécurité de confiance partielle de WPF

Stratégie de sécurité de WPF - ingénierie de la plateforme

Stratégie de sécurité de WPF - ingénierie de sécurité

Sécurité d'accès du code

Sécurité et déploiement ClickOnce

Vue d'ensemble du langage XAML (WPF)

Autres ressources

Aide sur la sécurité des modèles et des pratiques pour les applications (page éventuellement en anglais)