Stratégie de sécurité WPF - Sécurité de la plateforme
Bien que Windows Presentation Foundation (WPF) fournit un large éventail de services de sécurité, il tire également parti des fonctionnalités de sécurité de la plateforme sous-jacente, qui inclut le système d’exploitation, le CLR et Internet Explorer. Ces couches combinent pour fournir à WPF un modèle de sécurité fort et de défense en profondeur qui tente d’éviter tout point de défaillance unique, comme illustré dans la figure suivante :
Le reste de cette rubrique décrit les fonctionnalités de chacune de ces couches qui se rapportent spécifiquement à WPF.
Sécurité du système d’exploitation
Le cœur de Windows fournit plusieurs fonctionnalités de sécurité qui constituent la base de sécurité pour toutes les applications Windows, y compris celles générées avec WPF. Cette rubrique décrit l’étendue de ces fonctionnalités de sécurité qui sont importantes pour WPF, ainsi que la façon dont WPF s’intègre avec eux pour fournir une défense plus approfondie.
Microsoft Windows XP Service Pack 2 (SP2)
Outre une révision générale et un renforcement de Windows, il existe trois fonctionnalités clés de Windows XP SP2 que nous aborderons dans cette rubrique :
Compilation /GS
Microsoft Windows Update.
Compilation /GS
Windows XP SP2 offre une protection en recompilant de nombreuses bibliothèques système principales, y compris toutes les dépendances WPF telles que le CLR, pour atténuer les dépassements de mémoire tampon. Pour ce faire, utilisez le paramètre /GS avec le compilateur de ligne de commande C/C++. Bien que les dépassements de mémoire tampon soient explicitement évités, la compilation /GS fournit un exemple de défense en profondeur contre les vulnérabilités potentielles qui sont créées par inadvertance ou malveillante par eux.
Historiquement, les dépassements de mémoire tampon ont été la cause de nombreux exploits de sécurité à impact élevé. Un dépassement de mémoire tampon se produit lorsqu’un attaquant tire parti d’une vulnérabilité de code qui permet l’injection de code malveillant qui écrit au-delà des limites d’une mémoire tampon. Cela permet ensuite à un attaquant de détourner le processus dans lequel le code s’exécute en remplaçant l’adresse de retour d’une fonction pour provoquer l’exécution du code de l’attaquant. Le résultat est du code malveillant qui exécute du code arbitraire avec les mêmes privilèges que le processus détourné.
À un niveau élevé, l’indicateur de compilateur -GS protège contre certains dépassements potentiels de mémoire tampon en injectant un cookie de sécurité spécial pour protéger l’adresse de retour d’une fonction qui a des mémoires tampons de chaîne locale. Une fois qu’une fonction est retournée, le cookie de sécurité est comparé à sa valeur précédente. Si la valeur a changé, un dépassement de mémoire tampon peut s’être produit et le processus est arrêté avec une condition d’erreur. L’arrêt du processus empêche l’exécution de code potentiellement malveillant. Pour plus d’informations, consultez -GS (Contrôle de sécurité de la mémoire tampon).
WPF est compilé avec l’indicateur /GS pour ajouter une autre couche de défense aux applications WPF.
Windows Vista
Les utilisateurs WPF sur Windows Vista bénéficieront des améliorations de sécurité supplémentaires du système d’exploitation, notamment l'« accès utilisateurLeast-Privilege », les vérifications d’intégrité du code et l’isolation des privilèges.
Contrôle de compte d’utilisateur (UAC)
Aujourd’hui, les utilisateurs Windows ont tendance à s’exécuter avec des privilèges d’administrateur, car de nombreuses applications les nécessitent pour l’installation ou l’exécution, ou les deux. La possibilité d’écrire des paramètres d’application par défaut dans le Registre est un exemple.
L’exécution avec des privilèges d’administrateur signifie vraiment que les applications s’exécutent à partir de processus auxquels des privilèges d’administrateur sont accordés. L’impact de la sécurité est que tout code malveillant qui détourne un processus exécuté avec des privilèges d’administrateur hérite automatiquement de ces privilèges, y compris l’accès aux ressources système critiques.
Une façon de se protéger contre cette menace de sécurité consiste à exécuter des applications avec le moins de privilèges requis. C’est ce que l’on appelle le principe du privilège minimum et est une fonctionnalité essentielle du système d’exploitation Windows. Cette fonctionnalité est appelée contrôle de compte d’utilisateur (UAC) et est utilisée par l’UAC Windows de deux façons clés :
Pour exécuter la plupart des applications avec des privilèges UAC par défaut, même si l’utilisateur est administrateur ; seules les applications qui ont besoin de privilèges d’administrateur s’exécutent avec des privilèges d’administrateur. Pour s’exécuter avec des privilèges d’administration, les applications doivent être explicitement marquées dans leur manifeste d’application ou en tant qu’entrée dans la stratégie de sécurité.
Pour fournir des solutions de compatibilité telles que la virtualisation. Par exemple, de nombreuses applications essaient d’écrire dans des emplacements restreints comme C :\Program Files. Pour les applications s’exécutant sous UAC, un autre emplacement par utilisateur existe qui ne nécessite pas de privilèges d’administrateur pour écrire. Pour les applications s’exécutant sous UAC, UAC virtualise C :\Program Files afin que les applications qui pensent qu’elles écrivent dessus écrivent réellement dans l’emplacement alternatif, par utilisateur. Ce type de travail de compatibilité permet au système d’exploitation d’exécuter de nombreuses applications qui n’ont pas pu s’exécuter précédemment dans l’UAC.
Vérifications d’intégrité du code
Windows Vista intègre des contrôles d’intégrité du code plus approfondis pour empêcher l’injection de code malveillant dans des fichiers système ou dans le noyau au moment de la charge/de l’exécution. Cela va au-delà de la protection des fichiers système.
Processus de droits limités pour les applications Browser-Hosted
Les applications WPF hébergées dans un navigateur s’exécutent dans le bac à sable de la zone Internet. L’intégration de WPF à Microsoft Internet Explorer étend cette protection avec une prise en charge supplémentaire.
Avertissement
Les XBAPs nécessitent des navigateurs anciens pour fonctionner, tels qu’Internet Explorer et les anciennes versions de Firefox. Ces navigateurs plus anciens ne sont généralement pas pris en charge sur Windows 10 et Windows 11. Les navigateurs modernes ne prennent plus en charge la technologie requise pour les applications XBAP en raison des risques de sécurité. Les plug-ins qui activent les XBAPs ne sont plus pris en charge. Pour plus d'informations, consultez Questions fréquentes sur les applications WPF hébergées dans un navigateur (XBAP).
Étant donné que les applications de navigateur XAML (XBAPs) sont généralement en bac à sable par le jeu d’autorisations de zone Internet, la suppression de ces privilèges n’endommage pas les applications de navigateur XAML (XBAPs) du point de vue de la compatibilité. Au lieu de cela, une couche de défense supplémentaire en profondeur est créée ; si une application en bac à sable est en mesure d’exploiter d’autres couches et de détourner le processus, le processus n’aura toujours que des privilèges limités.
Consultez Utilisation d’un compte d’utilisateur de privilège minimum.
Sécurité du Common Language Runtime
Le Common Language Runtime (CLR) offre un certain nombre d’avantages clés en matière de sécurité qui incluent la validation et la vérification, la sécurité d’accès au code (CAS) et la méthodologie critique de sécurité.
Validation et vérification
Pour assurer l’isolation et l’intégrité de l’assembly, le CLR utilise un processus de validation. La validation CLR garantit que les assemblages sont isolés en validant leur format de fichier exécutable portable (PE) pour les adresses qui pointent à l'extérieur de l’assemblage. La validation CLR valide également l’intégrité des métadonnées incorporées dans un assembly.
Pour garantir la cohérence des types, empêcher les problèmes de sécurité courants (par exemple, les dépassements de mémoire tampon) et permettre le sandboxing par l’intermédiaire de l’isolation de sous-processus, la sécurité CLR utilise le concept de vérification.
Les applications managées sont compilées dans le langage MSIL (Microsoft Intermediate Language). Quand les méthodes d'une application managée sont exécutées, son code MSIL est compilé en code natif par le biais de la compilation juste-à-temps (JIT). La compilation JIT inclut un processus de vérification qui applique de nombreuses règles de sécurité et de robustesse qui garantissent que le code ne le fait pas :
Violer les contrats de type
Introduire des dépassements de mémoire tampon
Mémoire à accès intense.
Le code managé qui n’est pas conforme aux règles de vérification n’est pas autorisé à s’exécuter, sauf s’il est considéré comme du code approuvé.
L’avantage du code vérifiable est une raison essentielle pour laquelle WPF s’appuie sur le .NET Framework. Dans la mesure où le code vérifiable est utilisé, la possibilité d’exploiter les vulnérabilités possibles est considérablement réduite.
Sécurité de l’accès au code
Une machine cliente expose une grande variété de ressources auxquelles une application managée peut avoir accès, notamment au système de fichiers, au Registre, aux services d’impression, à l’interface utilisateur, à la réflexion et aux variables d’environnement. Avant qu’une application managée puisse accéder à l’une des ressources sur une machine cliente, elle doit disposer de l’autorisation .NET Framework pour ce faire. Une autorisation dans CAS est une sous-classe de la CodeAccessPermission; CAS implémente une sous-classe pour chaque ressource auxquelles les applications gérées peuvent accéder.
L’ensemble d’autorisations qu’une application managée reçoit lorsqu’elle commence à s’exécuter est appelée jeu d’autorisations et est déterminée par des preuves fournies par l’application. Pour les applications WPF, la preuve fournie est l’emplacement ou la zone à partir duquel les applications sont lancées. CAS identifie les zones suivantes :
Mon ordinateur. Applications lancées à partir de l'ordinateur client (entièrement de confiance).
Intranet local : Applications lancées à partir de l’intranet. (niveau de confiance moyen).
Internet : Applications lancées à partir d’Internet. (Confiance minimale).
Sites de confiance : Applications identifiées par un utilisateur comme étant approuvées. (Confiance minimale).
Sites non fiables : Applications identifiées par un utilisateur comme non approuvées. (non approuvé).
Pour chacune de ces zones, CAS fournit un jeu d’autorisations prédéfini qui inclut les autorisations qui correspondent au niveau de confiance associé à chacune d'elles. Voici quelques-uns des éléments suivants :
FullTrust : Pour les applications lancées à partir de la zone Mon Ordinateur. Toutes les autorisations possibles sont accordées.
LocalIntranet : Pour les applications lancées à partir de la zone intranet local. Un sous-ensemble d’autorisations est accordé pour fournir un accès modéré aux ressources d’une machine cliente, notamment le stockage isolé, l’accès illimité à l’interface utilisateur, les boîtes de dialogue de fichiers illimitées, la réflexion limitée, l’accès limité aux variables d’environnement. Les autorisations pour les ressources critiques comme le Registre ne sont pas fournies.
Internet : Pour les applications lancées à partir de la zoneInternet ou Sites de confiance. Un sous-ensemble d’autorisations est accordé pour fournir un accès limité aux ressources d’un ordinateur client, y compris le stockage isolé, le fichier ouvert uniquement et l’interface utilisateur limitée. Essentiellement, ce jeu d’autorisations isole les applications de l’ordinateur client.
Les applications identifiées comme appartenant à la zone Sites non fiables ne reçoivent aucune autorisation par CAS tout court. Par conséquent, un jeu d’autorisations prédéfini n’existe pas pour eux.
La figure suivante illustre la relation entre les zones, les jeux d’autorisations, les autorisations et les ressources :
Les restrictions du bac à sable de sécurité de zone Internet s’appliquent également à tout code importé par un XBAP à partir d’une bibliothèque système, y compris WPF. Cela garantit que chaque bit du code est verrouillé, même WPF. Malheureusement, pour pouvoir s’exécuter, un XBAP doit exécuter des fonctionnalités qui nécessitent plus d’autorisations que celles activées par le bac à sable de sécurité de zone Internet.
Avertissement
Les XBAPs nécessitent des anciens navigateurs pour fonctionner, tels qu’Internet Explorer et les anciennes versions de Firefox. Ces navigateurs plus anciens ne sont généralement pas pris en charge sur Windows 10 et Windows 11. Les navigateurs modernes ne prennent plus en charge la technologie requise pour les applications XBAP en raison des risques de sécurité. Les plug-ins qui activent les XBAPs ne sont plus pris en charge. Pour plus d’informations, consultez Foire aux questions sur les applications hébergées par un navigateur WPF (XBAP).
Considérez une application XBAP qui inclut la page suivante :
FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();
// Perform operation that uses the assert
// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();
Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()
' Perform operation that uses the assert
' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()
Pour exécuter ce XBAP, le code WPF sous-jacent doit exécuter plus de fonctionnalités que ce qui est disponible pour le XBAP appelant, notamment :
Création d’un handle de fenêtre (HWND) pour le rendu
Distribution de messages
Chargement de la police Tahoma
Du point de vue de la sécurité, l’autorisation d’un accès direct à l’une de ces opérations à partir de l’application bac à sable (sandbox) serait catastrophique.
Heureusement, WPF prend en charge cette situation en permettant l'exécution de ces opérations avec des privilèges élevés pour le compte de l'application isolée. Bien que toutes les opérations WPF soient vérifiées par rapport aux autorisations limitées de sécurité de zone Internet du domaine d’application du XBAP, WPF (comme avec d’autres bibliothèques système) reçoit un jeu d’autorisations qui inclut toutes les autorisations possibles.
Cela nécessite que WPF reçoive des privilèges élevés tout en empêchant ces privilèges d’être régis par le jeu d’autorisations de zone Internet du domaine d’application hôte.
WPF effectue cette opération à l’aide de la méthode Assert d’une autorisation. Le code suivant montre comment cela se produit.
FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();
// Perform operation that uses the assert
// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();
Dim fp As New FileIOPermission(PermissionState.Unrestricted)
fp.Assert()
' Perform operation that uses the assert
' Revert the assert when operation is completed
CodeAccessPermission.RevertAssert()
L'Assert empêche essentiellement les autorisations illimitées requises par WPF d’être limitées par les autorisations de zone Internet du XBAP.
Du point de vue de la plateforme, WPF est chargé d’utiliser correctement Assert ; une utilisation incorrecte de Assert pourrait permettre au code malveillant d’élever des privilèges. Par conséquent, il est important de n’appeler Assert qu’en cas de nécessité et de vérifier que les restrictions du bac à sable (sandbox) restent intactes. Par exemple, le code en bac à sable n’est pas autorisé à ouvrir des fichiers aléatoires, mais il est autorisé à utiliser des polices. WPF permet aux applications sandbox d’utiliser la fonctionnalité de police en appelant Assert et à WPF de lire les fichiers connus pour contenir ces polices pour le compte de l’application sandbox.
Déploiement ClickOnce
ClickOnce est une technologie de déploiement complète incluse dans .NET Framework et s’intègre à Visual Studio (consultez sécurité clickOnce et le déploiement pour plus d’informations). Les applications WPF autonomes peuvent être déployées à l’aide de ClickOnce, tandis que les applications hébergées par navigateur doivent être déployées avec ClickOnce.
Les applications déployées à l’aide de ClickOnce reçoivent une couche de sécurité supplémentaire sur la sécurité d’accès au code (CAS) ; En fait, les applications déployées ClickOnce demandent les autorisations dont elles ont besoin. Seules ces permissions sont accordées si elles ne dépassent pas l'ensemble des autorisations pour la zone à partir de laquelle l'application est déployée. En réduisant l’ensemble d’autorisations à ceux nécessaires uniquement, même s’ils sont inférieurs à ceux fournis par le jeu d’autorisations de la zone de lancement, le nombre de ressources auxquelles l’application a accès est réduit au minimum. Par conséquent, si l’application est détournée, le risque de dommages à la machine cliente est réduit.
Méthodologie de Security-Critical
Le code WPF qui utilise des autorisations pour activer le bac à sable de zone Internet pour les applications XBAP doit être conservé au plus haut degré possible d’audit et de contrôle de sécurité. Pour faciliter cette exigence, .NET Framework fournit une nouvelle prise en charge de la gestion du code qui élève les privilèges. Plus précisément, le CLR vous permet d’identifier le code qui élève les privilèges et de les marquer avec le SecurityCriticalAttribute; tout code non marqué avec SecurityCriticalAttribute devient transparent à l’aide de cette méthodologie. À l’inverse, le code managé qui n’est pas marqué avec SecurityCriticalAttribute n’est pas empêché d’élever les privilèges.
Avertissement
Les XBAPs nécessitent des anciens navigateurs pour fonctionner, tels qu’Internet Explorer et les anciennes versions de Firefox. Ces navigateurs plus anciens ne sont généralement pas pris en charge sur Windows 10 et Windows 11. Les navigateurs modernes ne prennent plus en charge la technologie requise pour les applications XBAP en raison des risques de sécurité. Les plug-ins qui activent les XBAPs ne sont plus pris en charge. Pour plus d’informations, consultez Foire aux questions concernant les applications WPF hébergées dans un navigateur (XBAP).
La méthodologie critique de sécurité permet d’organiser le code WPF qui élève le privilège dans le noyau critique de sécurité, en laissant le reste transparent. L’isolation du code critique pour la sécurité permet à l’équipe d’ingénierie WPF de concentrer une analyse de sécurité et un contrôle de code source supplémentaires sur le noyau critique de sécurité au-dessus et au-delà des pratiques de sécurité standard (voir stratégie de sécurité WPF - Ingénierie de sécurité).
Notez que .NET Framework autorise le code approuvé à étendre le bac à sable de zone Internet XBAP en permettant aux développeurs d’écrire des assemblys managés marqués avec AllowPartiallyTrustedCallersAttribute (APTCA) et déployés sur le Global Assembly Cache (GAC) de l’utilisateur. Le marquage d’un assembly avec APTCA est une opération de sécurité hautement sensible, car il permet à tout code d’appeler cet assembly, y compris du code malveillant à partir d’Internet. La prudence extrême et les meilleures pratiques doivent être utilisées lorsque vous effectuez cette opération et les utilisateurs doivent choisir de faire confiance à ce logiciel pour qu’il soit installé.
Sécurité Microsoft Internet Explorer
Au-delà de la réduction des problèmes de sécurité et de la simplification de la configuration de la sécurité, Microsoft Internet Explorer 6 (SP2) contient plusieurs fonctionnalités qui améliorent la sécurité des utilisateurs d’applications de navigateur XAML (XBAPs). La poussée de ces fonctionnalités tente de permettre aux utilisateurs de mieux contrôler leur expérience de navigation.
Avertissement
Pour fonctionner, les XBAPs nécessitent des navigateurs obsolètes, tels qu'Internet Explorer et d'anciennes versions de Firefox. Ces navigateurs plus anciens ne sont généralement pas pris en charge sur Windows 10 et Windows 11. Les navigateurs modernes ne prennent plus en charge la technologie requise pour les applications XBAP en raison des risques de sécurité. Les plug-ins qui activent les XBAPs ne sont plus pris en charge. Pour plus d’informations, consultez Foire aux questions sur les applications hébergées par un navigateur WPF (XBAP).
Avant IE6 SP2, les utilisateurs peuvent être soumis à l’une des opérations suivantes :
Affichage de fenêtres intempestives aléatoires.
Redirection de script confuse.
De nombreux dialogues de sécurité sur certains sites Web.
Dans certains cas, les sites Web non fiables tentent d’inciter les utilisateurs à usurper l’interface utilisateur d’installation ou à afficher à plusieurs reprises une boîte de dialogue d’installation de Microsoft ActiveX, même si l’utilisateur peut l’avoir annulé. En utilisant ces techniques, il est possible qu’un nombre important d’utilisateurs aient été trompés dans la prise de mauvaises décisions qui se sont traduites par l’installation d’applications espions.
IE6 SP2 comprend plusieurs fonctionnalités pour atténuer ces types de problèmes, qui tournent autour du concept d’initiation utilisateur. IE6 SP2 détecte à quel moment un utilisateur a cliqué sur un lien ou un élément de page avant une action (opération connue sous le nom d’intervention de l’utilisateur) et la traite autrement qu’une action similaire déclenchée par le script d’une page. Par exemple, IE6 SP2 intègre un Pop-Up Blocker qui détecte lorsqu’un utilisateur clique sur un bouton avant la création d’une fenêtre contextuelle. Cela permet à IE6 SP2 d’autoriser la plupart des fenêtres contextuelles innocues tout en empêchant les fenêtres contextuelles que les utilisateurs ne demandent ni ne veulent. Les fenêtres contextuelles bloquées sont retenues par la nouvelle barre d’informations , permettant à l’utilisateur de remplacer manuellement le blocage et d’afficher la fenêtre contextuelle.
La même logique d’intervention de l’utilisateur est également appliquée aux invites de sécurité Ouvrir/Enregistrer. Les boîtes de dialogue d’installation ActiveX sont toujours bloquées sous la barre d’informations, sauf si elles représentent une mise à niveau à partir d’un contrôle précédemment installé. Ces mesures combinent pour offrir aux utilisateurs une expérience utilisateur plus sûre et plus contrôlée, car elles sont protégées contre les sites qui les harcèlent pour installer des logiciels indésirables ou malveillants.
Ces fonctionnalités protègent également les clients qui utilisent IE6 SP2 pour accéder aux sites web qui leur permettent de télécharger et d’installer des applications WPF. En particulier, cela est dû au fait que IE6 SP2 offre une meilleure expérience utilisateur qui réduit la possibilité pour les utilisateurs d’installer des applications malveillantes ou devious, quelle que soit la technologie utilisée pour la générer, y compris WPF. WPF ajoute à ces protections à l’aide de ClickOnce pour faciliter le téléchargement de ses applications sur Internet. Étant donné que les applications de navigateur XAML (XBAPs) s’exécutent dans un bac à sable de sécurité de zone Internet, elles peuvent être lancées en toute transparence. En revanche, les applications WPF autonomes nécessitent une confiance totale pour s’exécuter. Pour ces applications, ClickOnce affiche une boîte de dialogue de sécurité pendant le processus de lancement pour notifier l’utilisation des exigences de sécurité supplémentaires de l’application. Toutefois, cela doit être initié par l’utilisateur, est également régi par la logique initiée par l’utilisateur et peut être annulé.
Internet Explorer 7 intègre et étend les fonctionnalités de sécurité d’IE6 SP2 dans le cadre d’un engagement continu à la sécurité.
Voir aussi
.NET Desktop feedback