Stratégie de sécurité de 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. Cela est accompli en utilisant le paramètre /GS avec le compilateur de ligne de commande C/C++. Même s'il est clairement préférable d'éviter les dépassements de mémoire, 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é à fort impact. Un dépassement de mémoire tampon se produit quand 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 du code arbitraire avec les mêmes privilèges que le processus détourné.

À un niveau élevé, l’indicateur du 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. Après le retour d'une fonction, le cookie de sécurité est comparé à sa valeur précédente. Si la valeur a changé, cela signifie qu'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. 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 utilisateur avec privilège minimum », 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. Le fait de pouvoir écrire les paramètres d'application par défaut dans le Registre en est un exemple.

Une exécution avec des privilèges d'administrateur signifie en réalité que les applications s'exécutent à partir de processus auxquels sont accordés des privilèges d'administrateur. L'impact de cela sur la sécurité 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 menace de sécurité est d'exécuter les 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 les privilèges de contrôle de compte d'utilisateur par défaut, même si l'utilisateur est 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 entrée dans la stratégie de sécurité.

• Pour fournir des solutions de compatibilité comme la virtualisation. Par exemple, de nombreuses applications tentent d'écrire dans des emplacements restreints comme C:\Program Files. Pour les applications s'exécutant sous contrôle de compte d'utilisateur, il existe un autre emplacement par utilisateur dans lequel les opérations d'écriture ne nécessitent pas de privilèges d'administrateur. Pour les applications s'exécutant sous contrôle de compte d'utilisateur, cette fonctionnalité virtualise C:\Program Files de sorte que les applications qui pensent écrire à cet emplacement écrivent en réalité à l'autre emplacement 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 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 hébergées par un navigateur

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

É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é. En revanche, une couche de défense en profondeur supplémentaire est créée. Si une application sandbox peut exploiter d'autres couches et détourner le processus, celui-ci aura encore 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 assemblys sont isolés en validant leur format de fichier Exécutable portable (PE) pour les adresses qui pointent en dehors 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é des types, évitez les problèmes de sécurité courants (par exemple, les dépassements de mémoire tampon) et activez le bac à sable via l’isolation des sous-processus, la sécurité CLR utilise le concept de vérification.

Les applications managées sont compilées en 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 viole pas les contrats des types ;

• n'introduit pas de dépassements de mémoire tampon ;

• n'accède pas intensément à 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 soit considéré comme un 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ù du code vérifiable est utilisé, la possibilité d'exploiter des failles éventuelles est considérablement réduite.

Sécurité d'accès du code

Un ordinateur client expose une grande variété de ressources auxquelles une application managée peut avoir accès, notamment 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 à l’une des ressources sur une machine cliente, elle doit disposer de l’autorisation .NET Framework pour ce faire. Une autorisation dans le système d’administration centrale est une sous-classe de l’objet CodeAccessPermission; CAS implémente une sous-classe pour chaque ressource que les applications managé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. Le cas identifie les zones suivantes :

• Poste de travail : applications lancées à partir de l'ordinateur client (entièrement fiable).

• Intranet local : applications lancées à partir de l'intranet (niveau de confiance moyen).

• Internet. applications lancées à partir d'Internet (niveau de confiance le plus faible).

• Sites de confiance : applications identifiées par un utilisateur comme dignes de confiance (niveau de confiance le plus faible).

• Sites non fiables : applications identifiées par un utilisateur comme étant non fiables (non approuvé).

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 d’eux. Il s’agit notamment des paramètres suivants :

• FullTrust : pour les applications lancées à partir de la zone Poste de travail. 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'un ordinateur client : emplacement de stockage isolé, accès illimité à l'interface utilisateur, accès illimité aux boîtes de dialogue de fichier, réflexion limitée et accès limité aux variables d'environnement. Les autorisations permettant d'accéder aux ressources critiques comme le Registre ne sont pas fournies.

• Internet. pour les applications lancées à partir 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 : emplacement de stockage isolé, ouverture des fichiers uniquement et interface utilisateur limitée. Essentiellement, ce jeu d’autorisations isole les applications de l’ordinateur client.

Les applications identifiées comme provenant de la zone Sites non approuvés n’ont pas d’autorisations par le cas du tout. Par conséquent, il n'existe pas de jeu d'autorisations prédéfini pour ces applications.

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.

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é, il serait catastrophique d'autoriser l'application sandbox à accéder directement à l'une de ces opérations.

Heureusement, WPF répond à cette situation en autorisant ces opérations à s’exécuter avec des privilèges élevés pour le compte de l’application en bac à sable. 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 en donne l'illustration.

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’assertion 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 responsable de l’utilisation correcte de Assert ; une utilisation incorrecte d’Assert peut 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 mode sandbox n'est pas autorisé à ouvrir des fichiers aléatoires, mais il est autorisé à utiliser des polices. WPF permet aux applications en bac à sable d’utiliser la fonctionnalité de police en appelant Assert et pour WPF de lire les fichiers connus pour contenir ces polices pour le compte de l’application en bac à sable.

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é et déploiement ClickOnce pour obtenir des informations détaillées). 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 autorisations leur sont accordées si elles ne dépassent pas le jeu d'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, les risques de dommages sur l'ordinateur client sont réduits.

Méthodologie critique de sécurité

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 le privilège et de le marquer avec le SecurityCriticalAttribute; tout code non marqué avec SecurityCriticalAttribute devient transparent à l’aide de cette méthodologie. Inversement, le code managé qui n'est pas marqué avec SecurityCriticalAttribute est empêché d'élever le privilège.

La méthodologie critique de sécurité permet l’organisation du code WPF qui élève les privilèges dans le noyau critique de sécurité, avec le reste étant 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. Marquer un assembly avec APTCA est une opération de sécurité très sensible, car n'importe quel code peut appeler cet assembly, y compris du code malveillant en provenance d'Internet. Cette opération exige la plus grande prudence et le respect des meilleures pratiques. De plus, les utilisateurs doivent décider d'approuver ce logiciel pour pouvoir l'installer.

Sécurité de 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). L'idée-force de ces fonctionnalités est d'offrir aux utilisateurs un contrôle accru sur leur navigation.

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 ;

• nombreuses boîtes de dialogue 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é. Il possible que ces techniques aient amené un nombre significatif d'utilisateurs à prendre de mauvaises décisions aboutissant à l'installation de logiciels 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 lorsqu’un utilisateur a cliqué sur un lien ou un élément de page avant une action, appelée initiation de l’utilisateur, et le traite différemment lorsqu’une action similaire est déclenchée par le script sur une page. Par exemple, IE6 SP2 intègre un bloqueur contextuel 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 interceptées sous la nouvelle barre d’informations, ce qui permet à l’utilisateur de substituer le bloc manuellement 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 se combinent pour donner à l'utilisateur une expérience plus sûre et mieux contrôlée, puisqu'ils sont protégés contre les sites qui les poussent à 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. Cependant, cette opération nécessite également l'intervention de l'utilisateur et peut être annulée.

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

• Sécurité d’accès du code
• Sécurité
• Sécurité de confiance partielle de WPF
• Stratégie de sécurité de WPF - ingénierie de sécurité