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

  • Article

Trustworthy Computing (informatique de confiance) est une initiative de Microsoft qui vise à garantir la production de code sécurisé. L’un des éléments clés de l’initiative d’informatique digne de confiance est le cycle de vie du développement de la sécurité Microsoft (SDL). Le SDL est une pratique d’ingénierie utilisée conjointement avec des processus d’ingénierie standard pour faciliter la livraison de code sécurisé. Le SDL se compose de dix phases qui combinent les meilleures pratiques avec la formalisation, la méasurabilité et une structure supplémentaire, notamment :

  • analyse de la conception de la sécurité ;

  • contrôles de qualité basés sur des outils ;

  • Test d’intrusion

  • réexamen final de la sécurité ;

  • gestion de la sécurité du produit après lancement.

Spécificités de WPF

L’équipe d’ingénierie WPF s’applique et étend le SDL, dont la combinaison comprend les aspects clés suivants :

Modélisation des menaces

Analyse de la sécurité et outils de modification

Techniques de test

Gestion du code critique

Modélisation des menaces

La modélisation des menaces est un composant principal de SDL et sert à profiler un système pour déterminer les vulnérabilités de sécurité potentielles. Une fois les failles identifiées, la modélisation des menaces permet aussi de s'assurer que des mesures de prévention appropriées ont été prises.

D'un point de vue général, la modélisation des menaces comporte les étapes clés suivantes, ici appliquées à l'exemple d'une épicerie :

  1. Identification des ressources : les ressources d'une épicerie peuvent inclure les employés, un coffre-fort, les caisses et le stock.

  2. Énumération des points d’entrée : les points d'entrée d'une épicerie peuvent inclure les portes de devant et de derrière, les fenêtres, le quai de chargement et les climatiseurs.

  3. Réflexion sur les attaques possibles à l’encontre des ressources via les points d’entrée : dans une épicerie, le coffre-fort peut être la cible d’une attaque via le point d’entrée que constitue le climatiseur ; celui-ci pourrait être démonté et, par le passage ainsi libéré, permettre d’extraire le coffre-fort hors du magasin.

La modélisation des menaces est appliquée dans WPF et inclut les éléments suivants :

  • Comment l’analyseur XAML lit les fichiers, mappe du texte aux classes de modèle objet correspondantes et crée le code réel.

  • Comment un handle de fenêtre (hWnd) est créé, envoie des messages et est utilisé pour restituer le contenu d'une fenêtre.

  • Comment la liaison de données obtient les ressources et interagit avec le système.

Ces modèles de menace sont importants pour identifier les spécifications de conception de sécurité et les mesures de prévention pendant le processus de développement.

Analyse de la source et outils de modification

En plus des éléments manuels de révision du code de sécurité du SDL, l’équipe WPF utilise plusieurs outils pour l’analyse de la source et les modifications associées afin de réduire les vulnérabilités de sécurité. Une large gamme d’outils sources est utilisée et comprend les éléments suivants :

  • FXCop : recherche les problèmes de sécurité courants dans le code managé, depuis les règles d’héritage et l’utilisation de la sécurité d’accès du code jusqu’aux méthodes permettant d’interagir sans risque avec le code non managé. Consultez la page FXCop.

  • Prefix/Prefast : recherche les failles de sécurité et les problèmes de sécurité courants dans le code non managé, tels que les dépassements de mémoire tampon, les problèmes de chaîne de format et la vérification d’erreurs.

  • API interditesstrcpy : analyse le code source à la recherche d’une utilisation accidentelle de fonctions connues pour provoquer des problèmes de sécurité, telles que . Une fois identifiées, ces fonctions sont remplacées par des alternatives plus sécurisées.

Techniques de test

WPF utilise diverses techniques de test de sécurité qui incluent :

  • Test whitebox : les testeurs affichent le code source, puis créent des tests d’exploitation.

  • Test de la boîte noire : les testeurs tentent de trouver des failles de sécurité en examinant l’API et les fonctionnalités, puis d’attaquer le produit.

  • Régression des problèmes de sécurité provenant d’autres produits : le cas échéant, les problèmes de sécurité provenant de produits connexes sont testés. Par exemple, des variantes appropriées d’environ soixante problèmes de sécurité pour Internet Explorer ont été identifiées et essayées pour leur applicabilité à WPF.

  • Test de pénétration basé sur des outils à l’aide du test de fichier à données aléatoires (fuzzing)  : le test de fichier à données aléatoires (fuzzing) consiste à exploiter la plage d’entrées d’un lecteur de fichiers à travers diverses entrées. Un exemple dans WPF où cette technique est utilisée consiste à case activée pour l’échec dans le code de décodage d’image.

Gestion du code critique

Pour les applications de navigateur XAML (XBAPs), WPF génère un bac à sable de sécurité à l’aide de la prise en charge de .NET Framework pour marquer et suivre le code critique de sécurité qui élève les privilèges (voir Méthodologie critique de sécurité dans la stratégie de sécurité WPF - Sécurité de la plateforme). Compte tenu des hautes exigences de qualité en matière de sécurité sur le code critique de sécurité, un tel code bénéficie d'un niveau de contrôle supplémentaire sur le plan de la gestion de la source et de l'audit de sécurité. Environ 5 % à 10 % de WPF se composent de code critique de sécurité, qui est examiné par une équipe d’examen dédiée. Le processus de code source et d’archivage est géré par le suivi du code critique de sécurité et le mappage de chaque entité critique (c’est-à-dire, une méthode qui contient le code critique) à son état de validation. L'état de validation s'accompagne des noms d'un ou plusieurs réviseurs. Chaque build quotidienne de WPF compare le code critique à celui des builds précédentes à case activée pour les modifications non approuvées. Si un ingénieur modifie du code critique sans l'approbation de l'équipe de révision, celui-ci est identifié et corrigé immédiatement. Ce processus permet l’application et la maintenance d’un niveau d’examen particulièrement élevé du code de bac à sable WPF.

Avertissement

Les XBAPs nécessitent que les navigateurs hérités fonctionnent, tels qu’Internet Explorer et Firefox. Ces versions de navigateur plus anciennes ne sont généralement pas prises 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.

Voir aussi