Sécurité (WPF)

Lors du développement d’applications autonomes et hébergées par un navigateur Windows Presentation Foundation (WPF), vous devez prendre en compte 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 autonomes à confiance partielle avec ClickOnce n’est pas pris en charge. Toutefois, une application hôte à confiance totale peut créer une approbation AppDomain partielle à l’aide du modèle de complément .NET Framework. Pour plus d’informations, consultez WPF Add-Ins Vue d’ensemble.

Les applications hébergées par un navigateur WPF sont hébergées par Windows Internet Explorer ou Firefox, et peuvent être des applications de navigateur XAML (XBAPs) ou des documents XAML extensibles (XAML) pour plus d’informations, voir Vue d’ensemble des applications de navigateur XAML WPF.

Par défaut, les applications hébergées par le navigateur WPF s’exécutent dans un bac à sable de sécurité de confiance partielle, qui est limité au jeu d’autorisations de zoneInternet CAS par défaut. Cela isole efficacement les applications hébergées par le navigateur WPF à partir de l’ordinateur client de la même façon que vous vous attendiez à ce que les applications web classiques soient isolées. Un XBAP peut élever des privilèges, jusqu’à confiance totale, en fonction de la zone de sécurité de l’URL de déploiement et de la configuration de sécurité du client. Pour plus d’informations, consultez Sécurité de confiance partielle WPF.

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

Cette rubrique contient les sections suivantes :

• Navigation sécurisée

• Paramètres de sécurité logicielle de navigation web

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

• Désactivation des assemblys APTCA pour les applications clientes partiellement approuvées

• Comportement du bac à sable pour les fichiers XAML libres

• Ressources pour le développement d’applications WPF qui favorisent la sécurité

Navigation sécurisée

Pour les XBAPs, WPF distingue deux types de navigation : l’application et le navigateur.

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

Le type de contenu que peut naviguer un XBAP en toute sécurité est principalement déterminé par la méthode de navigation utilisée, qu'elle soit au sein de l'application ou du navigateur.

Sécurité de la navigation des applications

La navigation d’application est considérée comme sécurisée si elle peut être identifiée avec un URI de pack, qui prend en charge quatre types de contenu :

Les fichiers de ces types de contenu peuvent être accédés par l’utilisateur ou par programmation :

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

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

Sécurité de navigation dans le navigateur

La navigation dans le navigateur est considérée comme sécurisée uniquement dans les conditions suivantes :

• Navigation utilisateur. L’utilisateur navigue en cliquant sur l’élément Hyperlink qui se trouve dans le NavigationWindow principal, et non dans un Frame imbriqué.

• Zone. Le contenu accessible se trouve sur Internet ou sur l’intranet local.

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

Si un XBAP tente d’accéder au contenu d’une manière qui ne respecte pas ces conditions, un SecurityException est levé.

Paramètres de sécurité logicielle de navigation web

Les paramètres de sécurité de votre ordinateur déterminent l’accès accordé à n’importe quel logiciel de navigation web. Le logiciel de navigation web inclut n’importe quelle application ou composant qui utilise les API WinINet ou UrlMon , y compris Internet Explorer et PresentationHost.exe.

Internet Explorer fournit un mécanisme par lequel vous pouvez configurer les fonctionnalités autorisées à être exécutées par ou à partir d’Internet Explorer, y compris les éléments suivants :

• Composants dépendants du .NET Framework

• Contrôles et plug-ins ActiveX

• Téléchargements

• Écriture de scripts

• Authentification des utilisateurs

La collection de fonctionnalités qui peuvent être sécurisées de cette façon est configurée par zone pour les zones Internet, Intranet, Sites approuvés et Sites restreints . 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 s’affiche.

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

4. Cliquez sur le bouton Niveau personnalisé .

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

   

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

• XAML non structuré. Détermine si Internet Explorer peut accéder à des fichiers XAML non sécurisés. (Activer, désactiver et inviter des options).

• Applications de navigateur XAML. Détermine si Internet Explorer peut naviguer vers et exécuter les XBAP. (Activer, désactiver et inviter des options).

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

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

Outre les paramètres de sécurité disponibles via Les options Internet, les valeurs de Registre suivantes sont disponibles pour bloquer sélectivement un certain nombre de 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 répertorie les valeurs qui peuvent être définies.

Contrôle WebBrowser et contrôles de fonctionnalité

Le contrôle WPF WebBrowser peut être utilisé pour héberger du contenu web. Le contrôle WPF WebBrowser encapsule le contrôle ActiveX WebBrowser sous-jacent. WPF fournit une prise en charge de la sécurisation de votre application lorsque vous utilisez le contrôle WPF WebBrowser pour héberger du contenu web non approuvé. Toutefois, certaines fonctionnalités de sécurité doivent être appliquées directement par les applications utilisant le WebBrowser contrôle. Pour plus d’informations sur le contrôle ActiveX WebBrowser, consultez Présentations et didacticiels du contrôle WebBrowser.

Si le contrôle WPF WebBrowser est utilisé pour héberger du contenu web non approuvé, votre application doit utiliser une approbation AppDomain partielle pour aider à isoler le code de votre application contre le code de script HTML potentiellement malveillant. Cela est particulièrement vrai si votre application interagit avec le script hébergé à l’aide de la InvokeScript méthode et de la ObjectForScripting propriété. Pour plus d’informations, consultez WPF Add-Ins Vue d’ensemble.

Si votre application utilise le contrôle WPF WebBrowser , une autre façon d’augmenter la sécurité et d’atténuer les attaques consiste à activer les 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 d’applications qui hébergent le contrôle ActiveX WebBrowser, que le contrôle WPF WebBrowser encapsule. Les contrôles de fonctionnalité peuvent être configurés à l’aide de la fonction CoInternetSetFeatureEnabled ou en modifiant des valeurs dans le Registre. Pour plus d’informations sur les contrôles de fonctionnalités, consultez Présentation des contrôles de fonctionnalités et des contrôles de fonctionnalité Internet.

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

Étant donné que ces contrôles de fonctionnalité sont activés sans condition, une application de confiance totale peut être altérée par ces contrôles. Dans ce cas, s’il n’existe aucun risque de sécurité pour l’application spécifique et le contenu qu’il héberge, le contrôle de fonctionnalité correspondant peut être désactivé.

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

Pour votre exécutable, envisagez d’activer les contrôles de fonctionnalité suivants en définissant la valeur de Registre sur 1.

Pour votre exécutable, envisagez de désactiver le contrôle des fonctionnalités suivant en définissant la valeur du registre sur 0.

Si vous exécutez une application de navigateur XAML de confiance partielle (XBAP) qui inclut un contrôle WPF WebBrowser dans Windows Internet Explorer, WPF héberge le contrôle ActiveX WebBrowser dans l’espace d’adressage du processus Internet Explorer. Étant donné que 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 XBAPs s’exécutant dans Internet Explorer obtiennent également un niveau de sécurité supplémentaire par rapport 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 Présentation et utilisation en mode protégé Internet Explorer.

Désactivation des assemblys APTCA pour les applications clientes partiellement approuvées

Lorsque des assemblys managés sont installés dans le Global Assembly Cache (GAC), ils deviennent entièrement approuvés, car l’utilisateur doit fournir une autorisation explicite pour les installer. Étant donné qu’elles sont entièrement approuvées, seules les applications clientes gérées entièrement approuvées peuvent les utiliser. Pour permettre aux applications partiellement approuvées de les utiliser, elles doivent être marquées avec le AllowPartiallyTrustedCallersAttribute (APTCA). Seuls les assemblages qui ont été testés pour être sûrs pour une exécution dans une confiance partielle doivent être marqués avec cet attribut.

Toutefois, il est possible qu’un assembly APTCA présente une faille de sécurité après avoir été installé dans le GAC. Une fois qu’une faille de sécurité est détectée, les éditeurs d’assembly peuvent produire une mise à jour de sécurité pour résoudre le problème sur les installations existantes et pour vous protéger contre les installations qui peuvent se produire après la découverte du problème. L’une des options de la mise à jour consiste à désinstaller l’assembly, bien que cela puisse interrompre d’autres applications clientes entièrement approuvées qui utilisent l’assembly.

WPF fournit un mécanisme par lequel un assembly APTCA peut être désactivé pour les XBAPs partiellement approuvés 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 également créer une valeur dans cette clé qui active ou désactive l’assembly. Voici les détails de la valeur :

• Nom de la valeur : APTCA_FLAG.

• Type de valeur : REG_DWORD.

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

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

Comportement du bac à sable pour les fichiers XAML libres

Les fichiers XAML libres sont des fichiers XAML de balisage uniquement qui ne dépendent d'aucun code-behind, d'aucun gestionnaire d’événements, ni d'un assembly spécifique à l'application. Lorsque des fichiers XAML libres sont accessibles directement à partir du navigateur, ils sont chargés dans un bac à sable de sécurité en fonction du jeu d’autorisations de zone Internet par défaut.

Toutefois, le comportement de sécurité est différent lorsque des fichiers XAML autonomes sont navigués vers à partir d'une NavigationWindow ou d'une Frame dans une application autonome.

Dans les deux cas, le fichier XAML libre qui est parcouru hérite des autorisations de son application hôte. Toutefois, ce comportement peut être indésirable du point de vue de la sécurité, en particulier si un fichier XAML libre a été produit par une entité qui n’est pas approuvée ou inconnue. Ce type de contenu est appelé contenu externe, et Frame et NavigationWindow peuvent être configurés pour l'isoler lorsqu'on y accède. L’isolation est obtenue en définissant la propriété SandboxExternalContent sur true, comme illustré dans les exemples suivants pour Frame et NavigationWindow:

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

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

Avec ce paramètre, le contenu externe est chargé dans un processus distinct du processus qui héberge l’application. Ce processus est limité au jeu d’autorisations de la zone Internet par défaut, ce qui l’isole efficacement de l’application d’hébergement et de l’ordinateur client.

Ressources pour le développement d’applications WPF qui favorisent la sécurité

Voici quelques ressources supplémentaires pour aider à développer des applications WPF qui favorisent la sécurité :

Voir aussi

• Sécurité de confiance partielle de WPF
• Stratégie de sécurité WPF - Sécurité de la plateforme
• Stratégie de sécurité de WPF - ingénierie de sécurité
• Conseils de sécurité sur les modèles et pratiques pour les applications
• Sécurité d’accès du code
• Sécurité et déploiement ClickOnce
• XAML dans WPF