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

Article
08/10/2011

Bien que Windows Presentation Foundation (WPF) fournisse divers 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 se combinent pour fournir à WPF un modèle de sécurité de défense en profondeur renforcé qui essaie d'éviter le moindre point de défaillance, comme cela est illustré dans l'image suivante :

Illustration de la sécurité WPF

Le reste de cette rubrique traite des fonctionnalités dans chacune de ces couches qui ont un rapport spécifique à WPF.

Cette rubrique comprend les sections suivantes.

Sécurité du système d'exploitation
Sécurité Common Language Runtime
Sécurité de Microsoft Internet Explorer
Rubriques connexes

Sécurité du système d'exploitation

Le niveau minimum requis par WPF pour le système d'exploitation est Windows XP SP2. Le cœur de Windows XP SP2 fournit plusieurs fonctionnalités de sécurité qui constituent la fondation de sécurité de toutes les applications Windows, y compris celles créées avec WPF. Windows Vista intègre les fonctionnalités de sécurité de WPF et les étend. Cette rubrique traite de l'ampleur de ces fonctionnalités de sécurité qui sont importantes pour WPF, ainsi que de la manière dont WPF les intègre pour offrir une défense en profondeur supplémentaire.

Microsoft Windows XP Service Pack 2 (SP2)

En plus d'une révision générale et d'un renforcement de Windows, trois fonctionnalités clés de Windows XP SP2 seront abordées dans cette rubrique :

Compilation /GS
Microsoft Windows Update.

Compilation /GS

Windows XP SP2 offre une protection en recompilant de nombreuses bibliothèques de système de base, y compris toutes les dépendances WPF telles que le CLR, pour aider à atténuer les dépassements de mémoire tampon. Cela est accompli en utilisant le paramètre /GS avec le compilateur de ligne de commande C/C++. Bien que les dépassements de mémoire tampon doivent être évités explicitement, la compilation /GS fournit un exemple de défense en profondeur contre les vulnérabilités potentielles qui sont créées par inadvertance ou par malveillance par ces derniers.

Historiquement, les dépassements de mémoire tampon ont été la cause de nombreuses attaques de sécurité à impact élevé. Un dépassement de mémoire tampon se produit lorsqu'un intrus tire parti d'une vulnérabilité de code qui autorise l'injection de code malveillant qui écrit au-delà des limites d'une mémoire tampon. Cela permet ensuite à un intrus de détourner le processus dans lequel s'exécute le code en remplaçant l'adresse de retour d'une fonction pour provoquer l'exécution du code de l'intrus. Le résultat est un code malveillant qui exécute le code arbitraire avec les mêmes privilèges que le processus détourné.

À un niveau élevé, l'indicateur de compilateur /GS protège contre quelques dépassements de mémoire tampon potentiels en injectant un cookie de sécurité spécial pour protéger l'adresse de retour d'une fonction qui a des mémoires tampon de chaînes locales. Après avoir retourné une fonction, le cookie de sécurité est comparé avec sa valeur précédente. Si la valeur a changé, un dépassement de mémoire tampon a pu se produire 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. Consultez /GS (Vérification de la sécurité de la mémoire tampon) pour plus de détails.

WPF est compilé avec l'indicateur /GS pour ajouter encore une autre couche de défense aux applications WPF.

Améliorations de Microsoft Windows Update

Microsoft Windows Update a également été amélioré dans Windows XP SP2 pour simplifier le processus de téléchargement et d'installation des mises à jour. Ces modifications améliorent considérablement la sécurité pour les clients WPF en les aidant à s'assurer que leurs systèmes sont à jour, en particulier en ce qui concerne les mises à jour de sécurité.

Windows Vista

Les utilisateurs WPF sur Windows Vista bénéficieront des améliorations de sécurité supplémentaires du système d'exploitation, y compris « l'accès utilisateur de moindre privilège », les contrôles d'intégrité du code, et l'isolation de privilège.

Contrôle de compte d'utilisateur (UAC)

Aujourd'hui, les utilisateurs de Windows ont tendance à travailler avec les privilèges d'administrateur car de nombreuses applications en ont besoin pour l'installation, l'exécution, ou les deux à la fois. Être en mesure d'écrire des paramètres d'application par défaut sur le Registre en est un exemple.

L'exécution à partir de privilèges d'administrateur signifie en réalité que les applications s'exécutent à partir de processus disposant de privilèges d'administrateur. L'impact de sécurité qui en résulte est que tout code malveillant qui détourne un processus s'exécutant avec des privilèges d'administrateur héritera automatiquement de ces privilèges, y compris l'accès aux ressources système critiques.

Une façon de se protéger contre cette atteinte à la sécurité est d'exécuter des applications avec le moins de privilèges requis. Ceci est reconnu comme le principe de privilège minimum, c'est une fonctionnalité principale du système d'exploitation Windows Vista. Cette fonctionnalité est appelée Contrôle de compte d'utilisateur (UAC), et est utilisée par Windows Vista de deux manières essentielles :

Pour exécuter la plupart des applications avec les privilèges de contrôle de compte d'utilisateur par défaut, même si l'utilisateur est un administrateur ; seules les applications qui ont besoin de privilèges d'administrateur s'exécuteront avec les privilèges d'administrateur. Pour s'exécuter avec des privilèges d'administrateur, les applications doivent être marquées explicitement dans leur manifeste d'application ou comme une entrée dans la stratégie de sécurité.
Pour fournir des solutions de compatibilité comme la virtualisation. Par exemple, de nombreuses applications essaient d'écrire dans les emplacements restreints comme C:\Program Files. Pour les applications qui s'exécutent sous contrôle de compte d'utilisateur, il existe un autre emplacement par utilisateur qui ne nécessite pas de privilèges d'administrateur pour écrire dessus. Pour les applications qui s'exécutent sous contrôle de compte d'utilisateur, le contrôle de compte d'utilisateur virtualise C:\Program Files afin que les applications qui pensent écrire dessus écrivent en réalité sur l'autre emplacement par utilisateur. Ce type de travail de compatibilité permet au système d'exploitation d'exécuter de nombreuses applications qui ne pouvaient pas s'exécuter précédemment dans le contrôle de compte d'utilisateur.

Contrôles d'intégrité du code

Windows Vista intègre des contrôles d'intégrité du code plus approfondis pour aider à empêcher le code malveillant d'être injecté dans les fichiers systèmes ou dans le noyau au chargement/moment de l'exécution. Cela va au delà de la protection des fichiers système.

Processus de droits limités pour les applications hébergées par navigateur

Les applications WPF hébergées par un navigateur s'exécutent dans le bac à sable (sandbox) de zone Internet. L'intégration de WPF à Microsoft Internet Explorer étend cette protection en assurant une prise en charge supplémentaire.

Internet Explorer 6 Service Pack 2 et Internet Explorer 7 pour XP

WPF tire parti de la sécurité du système d'exploitation en limitant les privilèges de processus pour XAML browser applications (XBAPs) pour une meilleure protection. Avant qu'une application WPF hébergée par navigateur ne soit lancée, le système d'exploitation crée un processus hôte qui supprime les privilèges inutiles du jeton de processus. Quelques exemples des privilèges supprimés incluent la capacité d'arrêter l'ordinateur de l'utilisateur, de charger des pilotes et d'accéder en lecture à tous les fichiers de l'ordinateur.

Internet Explorer 7 pour Vista

Dans Windows Internet Explorer 7, les applications WPF s'exécutent en mode protégé. Plus particulièrement, XAML browser applications (XBAPs) s'exécutent avec une intégrité de niveau moyen.

Couche de défense en profondeur

Puisque les XAML browser applications (XBAPs) sont en général mis dans le bac à sable (sandbox) par le jeu d'autorisations de zone Internet, la suppression de ces privilèges ne nuit pas aux XAML browser applications (XBAPs) en terme de compatibilité. À la place, une couche de défense en profondeur supplémentaire est créée ; si une application placée dans le bac à sable (sandbox) 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 Using a Least-Privileged User Account (page éventuellement en anglais)

Sécurité Common Language Runtime

Le common language runtime (CLR) offre plusieurs avantages de sécurité clés qui incluent la validation et la vérification, Code Access Security (CAS), et la méthodologie de sécurité critique.

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 assemblys sont isolés en validant leur format de fichier Portable Executable (PE) pour les adresses qui pointent vers l'extérieur de l'assembly. La validation CLR valide également l'intégrité des métadonnées incorporées dans un assembly.

Pour garantir la sécurité de type, empêcher les problèmes de sécurité communs (tels que les dépassements de mémoire tampon) et permettre le sandboxing via l'isolation de sous-processus, la sécurité CLR utilise le concept de vérification.

Les applications managées sont compilées dans Microsoft Intermediate Language (MSIL). Lorsque les méthodes dans une application managée sont exécutées, son 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 nombreuse règles de sécurité et de robustesse qui garantit que le code :

Ne viole pas des contrats de type
N'introduit pas de dépassements de mémoire tampon
N'accède pas sauvagement à la mémoire.

Le code managé qui ne se conforme pas aux règles de vérification n'est pas autorisé à s'exécuter, à moins qu'il ne soit considéré comme un code approuvé.

L'avantage du code vérifiable est la raison essentielle pour laquelle WPF génère sur le .NET Framework. Dans les limites d'utilisation du code vérifiable, la possibilité d'exploiter de possibles vulnérabilités est fortement réduite.

Sécurité d'accès du code

Un ordinateur client expose une large gamme de ressources auxquelles une application managée peut avoir accès, y compris le système de fichiers, le Registre, les services d'impression, l'interface utilisateur, la réflexion et les variables d'environnement. Avant qu'une application managée puisse accéder aux ressources d'un ordinateur client, elle doit disposer des autorisations .NET Framework Code Access Security (CAS) requises pour ce faire. Une autorisation dans CAS est une sous-classe de CodeAccessPermission ; CAS implémente une sous-classe pour chacune des ressources sur lesquelles des applications managées peuvent accéder.

Le jeu d'autorisations accordées à une application managée par CAS lorsqu'elle commence à s'exécuter est connu comme un jeu d'autorisations et déterminé par une preuve fournie par l'application. Pour les applications WPF, la preuve fournie est l'emplacement, ou zone, à partir duquel les applications sont lancées. CAS identifie les zones suivantes :

Poste de travail. Applications lancées de l'ordinateur client (d'un niveau de confiance suffisant).
Intranet local. Applications lancées de l'intranet. (d'un niveau de confiance moyen).
Internet. Applications lancées d'Internet. (d'un niveau de confiance faible).
Sites de confiance. Applications identifiées par un utilisateur comme dignes de confiance. (d'un niveau de confiance faible).
Sites non fiables. Applications identifiées par un utilisateur comme étant non fiables. (non fiable).

Pour chacune de ces zones, CAS fournit un jeu d'autorisations prédéfini qui inclut les autorisations qui correspondent au niveau d'approbation associé à chacun. Ces niveaux sont les suivants :

Confiance totale. Pour les applications lancées de la zone Poste de travail. Toutes les autorisations possibles sont accordées.
Intranet local. Pour les applications lancées de la zone Intranet local. Un sous-ensemble d'autorisations est accordé pour fournir l'accès modéré aux ressources d'un ordinateur client, y compris le stockage isolé, l'accès illimité à l'interface utilisateur, l'accès illimité aux boîtes de dialogue de fichier, la réflexion limitée et 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 de la zone Internet ou Sites de confiance. Un sous-ensemble d'autorisations est accordé pour octroyer un accès limité aux ressources d'un ordinateur client, y compris le stockage isolé, l'ouverture de fichier uniquement, et l'interface utilisateur limitée. Ces jeux d'autorisations isolent principalement les applications de l'ordinateur client.

Les applications identifiées comme provenant de la zone Sites non fiables ne se voient accorder aucune autorisation par CAS. Par conséquent, un jeu d'autorisations prédéfini n'existe pas pour ces applications.

L'image suivante illustre la relation entre zones, jeux d'autorisations, autorisations et ressources.

Jeux d'autorisations CAS

Les restrictions du bac à sable (sandbox) de la sécurité de la zone Internet s'appliquent aussi à tout code qu'un XBAP importe à 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 requièrent plus d'autorisations que celles activées par le bac à sable (sandbox) de la sécurité de la zone Internet.

Considérez une application XBAP qui inclut la page suivante :

            Dim fp As New FileIOPermission(PermissionState.Unrestricted)
            fp.Assert()

            ' Perform operation that uses the assert

            ' Revert the assert when operation is completed
            CodeAccessPermission.RevertAssert()

FileIOPermission fp = 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 qu'il y en a de disponibles au XBAP appelant, y compris :

Création d'un handle de fenêtre (hWnd) pour le rendu
Distribution de messages
Chargement de la police Tahoma

D'un point de vue de sécurité, l'autorisation de l'accès direct à chacune de ces opérations à partir de l'application placée dans le bac à sable (sandbox) serait catastrophique.

Heureusement, WPF prévoit cette situation en autorisant ces opérations à s'exécuter avec les privilèges élevés de la part de l'application placée dans le bac à sable (sandbox). Pendant que toutes les opérations WPF sont vérifiées par rapport aux autorisations de sécurité limitées de la zone Internet du domaine d'application du XBAP, WPF (comme avec d'autres bibliothèques système) se voit accorder un jeu d'autorisations qui inclut toutes les autorisations possibles

Cela nécessite que WPF reçoive des privilèges élevés en empêchant ces privilèges d'être gouvernés par le jeu d'autorisations de la zone Internet du domaine d'application hôte.

WPF fait cela en utilisant la méthode Assert d'une autorisation. Le code suivant affiche la manière dont cela se produit.

            Dim fp As New FileIOPermission(PermissionState.Unrestricted)
            fp.Assert()

            ' Perform operation that uses the assert

            ' Revert the assert when operation is completed
            CodeAccessPermission.RevertAssert()

FileIOPermission fp = new FileIOPermission(PermissionState.Unrestricted);
fp.Assert();

// Perform operation that uses the assert

// Revert the assert when operation is completed
CodeAccessPermission.RevertAssert();

La méthode Assert empêche essentiellement les autorisations illimitées requises par WPF d'être restreintes par les autorisations de la zone Internet du XBAP.

D'une perspective de plateforme, WPF est chargé d'utiliser l'assertion correctement ; une utilisation incorrecte de l'assertion pourrait permettre au code malveillant d'élever les privilèges. Par conséquent, il est ensuite important d'appeler l'assertion en cas de besoin, et de s'assurer que les restrictions de bac à sable (sandbox) restent intactes. Par exemple, le code figurant dans le bac à sable (sandbox) n'est pas autorisé à ouvrir des fichiers aléatoires, mais est autorisé à utiliser des polices. WPF permet aux applications placées dans le bac à sable (sandbox) d'utiliser les fonctionnalités de police en appelant Assert, et permet à WPF de lire des fichiers connus pour contenir ces polices de la part de l'application placée dans le bac à sable (sandbox).

Déploiement ClickOnce

ClickOnce est une technologie de déploiement complète incluse avec .NET Framework qui s'intègre à Microsoft Visual Studio (voir Vue d'ensemble du déploiement ClickOnce pour des informations détaillées). Les applications WPF autonomes peuvent être déployées en utilisant ClickOnce, alors que les applications hébergées par navigateur doivent être déployées avec ClickOnce.

Les applications déployées en utilisant ClickOnce disposent d'une couche de sécurité supplémentaire par rapport à Code Access Security (CAS) ; les applications ClickOnce déployées demandent les autorisations dont elles ont besoin. Seules ces autorisations leur sont accordées si elles ne dépassent pas le jeu d'autorisations pour la zone de laquelle l'application est déployée. En réduisant le jeu d'autorisations à celles qui sont nécessaires uniquement, même si elles sont moins nombreuses que celles fournies par l'autorisation de la zone de lancement, le nombre de ressources auxquelles a accès l'application est réduite au minimum. Par conséquent, si l'application est détournée, les dommages potentiels sur l'ordinateur du client sont réduits.

Méthodologie de sécurité critique

Le code WPF qui utilise des autorisations pour activer le bac à sable (sandbox) de la zone Internet pour les applications XBAP doit être maintenu au degré d'audit de sécurité et contrôle le plus élevé possible. Pour faciliter cette exigence, .NET Framework fournit une nouvelle prise en charge pour gérer le code qui élève le privilège. Spécifiquement, le CLR vous permet d'identifier le code qui élève le privilège et le marque avec SecurityCriticalAttribute ; tout code non marqué avec SecurityCriticalAttribute devient transparent à l'aide de cette méthodologie. Inversement, le code managé non marqué avec SecurityCriticalAttribute est empêché d'élever le privilège.

La méthodologie de sécurité critique autorise l'organisation de code WPF qui élève le privilège dans le noyau de sécurité critique, en laissant le reste transparent. L'isolation du code de sécurité critique permet à l'équipe d'ingénierie de WPF de se concentrer sur une analyse de la sécurité supplémentaire et un contrôle de source sur le noyau de sécurité critique au-delà des pratiques de sécurité standard (voir Stratégie de sécurité de WPF - ingénierie de sécurité).

Notez que .NET Framework autorise le code de confiance à étendre le bac à sable (sandbox) de la zone Internet XBAP en permettant aux développeurs d'écrire des assemblys managés qui sont marqués avec AllowPartiallyTrustedCallersAttribute (APTCA) et sont 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é très sensible car elle permet à tout code d'appeler cet assembly, y compris le code malveillant provenant d'Internet. Une prudence extrême et les meilleures pratiques doivent être utilisées lors de cette opération, et les utilisateurs doivent choisir d'approuver ce logiciel afin de pouvoir l'installer.

Sécurité de Microsoft Internet Explorer

En plus 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é pour les utilisateurs de XAML browser applications (XBAPs). La poussée de ces fonctionnalités tente d'autoriser les utilisateurs à un plus grand contrôle de leur expérience de navigation.

Avant IE6 SP2, les utilisateurs pouvaient être sujet à chacune des situations suivantes :

Fenêtres intempestives aléatoires.
Redirection confuse de script.
Nombreuses boîtes de dialogue sur certains sites Web.

Dans certains cas, les sites Web non fiables essayaient de piéger les utilisateurs en usurpant l'installation de l'user interface (UI) ou en affichant une boîte de dialogue d'installation Microsoft ActiveX à plusieurs reprises, bien que l'utilisateur ait pu l'annuler. Grâce à ces techniques, il est possible qu'un nombre significatif d'utilisateurs ait été contraints de prendre de mauvaises décisions qui ont entraîné l'installation d'applications de logiciel espion.

IE6 SP2 inclut plusieurs fonctionnalités axées autour du concept d'intervention de l'utilisateur qui limitent ces types de problèmes. IE6 SP2 détecte qu'un utilisateur a cliqué sur un lien ou élément de page avant une action (opération connue sous le nom d'intervention de l'utilisateur) et procède à un traitement différent de lorsqu'une action semblable est déclenchée par le script dans une page. Par exemple, IE6 SP2 intègre un bloqueur de fenêtres publicitaires intempestives qui détecte lorsqu'un utilisateur clique sur un bouton que la page ne crée une fenêtre intempestive. Cela permet à IE6 SP2 d'autoriser la plupart des menus contextuels inoffensifs tout en empêchant les fenêtres intempestives non demandées ni souhaitées par l'utilisateur. Les fenêtres intempestives bloquées sont interceptées sous la nouvelle Barre d'informations, qui permet à l'utilisateur de substituer le bloc manuellement et de consulter le menu contextuel.

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 de ActiveX sont toujours interceptées sous la Barre d'informations, sauf si elles représentent une mise à niveau d'un contrôle précédemment installé. Ces mesures se combinent pour donner à l'utilisateur une expérience plus sûre et mieux contrôlée puisqu'ils se sont protégés contre les sites qui les harcellent pour installer un logiciel non désiré ou malveillant.

Ces fonctionnalités protègent également les clients qui utilisent IE6 SP2 pour naviguer jusqu'aux sites Web qui leur permettent de télécharger et d'installer des applications WPF. Plus particulièrement, ceci est du au fait que IE6 SP2 offre une meilleure expérience utilisateur qui réduit les risques d'installation d'applications malveillantes ou déviantes qui ne respectent pas la technologie utilisée pour les générer, notamment WPF. WPF renforce ces protections en utilisant ClickOnce pour faciliter le téléchargement de ses applications via Internet. Puisque XAML browser applications (XBAPs) s'exécutent dans un bac à sable (sandbox) de sécurité de la zone Internet, elles peuvent être lancées de façon transparente. En revanche, les applications WPF autonomes requièrent la confiance totale pour s'exécuter. Pour ces applications, ClickOnce affichera une boîte de dialogue de sécurité pendant le processus de lancement pour notifier l'utilisation des conditions de sécurité supplémentaires de l'application. Toutefois, cette opération doit être initialisée par utilisateur, est également gouvernée par la logique initiée par l'utilisateur et peut être annulée.

Internet Explorer 7 intègre et étend les fonctions de sécurité de IE6 SP2 dans le cadre d'un engagement progressif de sécurité.