Stratégie de sécurité de Windows Presentation Foundation – ingénierie de sécurité

Article
08/22/2008

Mise à jour : novembre 2007

L'Informatique de confiance (Trusworthy Computing) est une initiative Microsoft pour garantir la production de code sécurisé. Un élément clé de l'initiative Informatique de confiance (Trusworthy Computing) est cycle de vie de la sécurité (SDL, Security Development Lifecycle) Microsoft. SDL est une pratique d'ingénierie utilisée en association avec des processus d'ingénierie standard pour faciliter la livraison de code sécurisé. SDL se compose de dix phases qui associent les meilleures pratiques avec la formalisation, la mesurabilité et la structure supplémentaire, dont les éléments suivants :

Analyse de la conception de la sécurité
Contrôles de qualité basés sur les outils
Test de pénétration
Dernière révision de sécurité
Gestion de la sécurité du produit après sortie commerciale

Caractéristiques spécifiques WPF

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

Modélisation des menaces

Analyse de Sécurité et outils de modification

Techniques de test

Gestion du code critique

Modélisation des menaces

La modélisation des menaces constitue un composant principal de SDL et est utilisée pour profiler un système afin de déterminer des vulnérabilités de sécurité potentielles. Une fois que les vulnérabilités sont identifiées, la modélisation des menaces garantit également que les atténuations appropriées sont en place.

À un niveau élevé, la modélisation des menaces implique les étapes clés suivantes en utilisant une épicerie comme exemple :

Identification des ressources. Parmi les ressources d'une épicerie, on peut englober les employés, un coffre-fort, des caisses enregistreuses et l'inventaire.
É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.
Enquête sur des attaques contre des ressources en utilisant des points d'entrée. Une attaque possible peut cibler le coffre-fort d'une épicerie via le point d'entrée de la climatisation ; le climatiseur peut être démonté et par le passage libéré, permettre d'extraire le coffre-fort hors du magasin.

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

Comment l'analyseur XAML lit des fichiers, mappe le 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 des données obtient des 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 atténuations de menace au cours du processus de développement.

Outils de modification et d'analyse de la source

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

FXCop : trouve des problèmes de sécurité communs dans le code managé allant des règles d'héritage pour l'utilisation de la sécurité d'accès du code à comment interagir sans risque avec le code non managé. Consultez FXCop (en anglais).
Préfixe/Prefast : trouve des vulnérabilités de sécurité et des problèmes de sécurité communs dans le code non managé tel que les dépassements de mémoire tampon, les problèmes de chaîne de mise en forme et la recherche des erreurs.
API interdites : recherche du code source pour identifier une utilisation accidentelle des fonctions connues pour provoquer des problèmes de sécurité, tels que strcpy. Une fois identifiées, ces fonctions sont remplacées par d'autres qui offrent plus de sécurité.

Techniques de test

WPF utilise diverses techniques de test de sécurité dont notamment :

Test boîte blanche : les testeurs affichent le code source, puis génèrent des tests d'attaque
Test boîte noire : les testeurs essaient de trouver des attaques de sécurité en examinant l'API et les fonctionnalités, puis essaient d'attaquer le produit.
Régresser des problèmes de sécurité venant d'autre produits : les problèmes de sécurité venant de produits connexes sont testés le cas échéant. Ainsi, des variantes appropriées de soixante problèmes de sécurité environ pour Internet Explorer ont été identifiées et testées pour vérifier si WPF peut leur être appliqué.
Test de pénétration basé sur des outils à travers des tests aléatoires (fuzzing) : les tests aléatoires sont l'exploitation de la plage d'entrée d'un lecteur de fichier à travers diverses entrées. Un exemple dans WPF où cette technique est utilisée est la recherche de l'échec dans le code de décodage de l'image.

Gestion du code critique

Pour les applications du navigateur XAML (XBAP), WPF génère un bac à sable (sandbox) de sécurité en utilisant la prise en charge .NET Framework pour baliser et suivre du code critique de sécurité qui élève des privilèges (consultez Méthodologie de sécurité critique dans Stratégie de sécurité de Windows Presentation Foundation – sécurité de la plateforme). Compte tenu des exigences élevées de qualité de la sécurité sur le code critique de sécurité, un tel code reçoit un niveau supplémentaire de contrôle de la gestion de la source et de l'audit de sécurité. 5 à 10 % environ de WPF est composé de code critique de sécurité, examiné par une équipe de révision dédiée. Le code source et le processus d'archivage sont gérés en suivant le code critique de sécurité et en mappant chaque entité critique (c'est-à-dire une méthode qui contient du code critique) à son état de validation. L'état de validation inclut les noms d'un ou plusieurs relecteurs. Chaque build diurne de WPF compare le code critique à celui des versions précédentes pour vérifier les modifications non autorisées. Si un ingénieur modifie du code critique sans approbation de l'équipe de révision, celui-ci est immédiatement identifié et corrigé. Ce processus permet l'application et la maintenance d'un niveau particulièrement élevé de surveillance sur le code du bac à sable (sandbox) WPF.