Brian Johnson
Responsable de programme
Microsoft Corporation

Résumé : Visual Studio 2005 simplifie l'écriture d'applications sécurisées pour les développeurs. Vous pouvez écrire du code non managé sécurisé ou accéder à des outils IDE qui vous aident à créer et à déployer des applications managées tirant parti du modèle Code Access Security. (11 pages imprimées)

Consultez l'article en anglais 

Sur cette page

Introduction
Améliorations de la sécurité pour le code natif
Améliorations de la sécurité pour le code managé
Autres améliorations de la sécurité
Conclusion

Introduction

Les développeurs veulent écrire des applications sécurisées, mais la plupart d'entre eux ne souhaitent pas consacrer trop de temps à apprendre les méthodes de sécurisation. Ils préfèrent écrire du code et des algorithmes qui résolvent le problème et livrer le produit sans avoir à se soucier de la sécurité. Actuellement, il n'est pourtant pas possible de livrer des applications et de les oublier par la suite. Il est indispensable de comprendre les implications, sur la sécurité, des décisions que nous prenons. Dans cette optique, les outils utilisés pour écrire et livrer les applications peuvent simplifier considérablement la fourniture d'applications sécurisées. Dans cet article, j'examinerai certaines fonctions de Visual Studio 2005 capables de vous aider à créer des applications sécurisées et fiables. La plupart des outils et améliorations apportés à Visual Studio 2005 peuvent avoir, moyennant un petit effort supplémentaire, des répercussions importantes sur la sécurité globale de vos applications.

Améliorations de la sécurité pour le code natif

Visual C++ est le seul compilateur Visual Studio qui vous permet de cibler directement un processeur (par exemple, créer des exe et des dll natifs non managés).

Dans cette section, nous aborderons les améliorations de la sécurité pour le code natif. Il est à noter que, sauf indication contraire, ces recommandations s'appliquent à Visual C++.

La plupart des problèmes de sécurité liés au code natif sont à classer dans la catégorie des saturations de tampon. Ces saturations se produisent quand des données dépassant la taille d'un tampon sont insérées dans une partie de la mémoire à partir de laquelle le code peut être exécuté. Le problème survient lorsqu'un intrus intelligent comprend exactement comment il peut parvenir à saturer le tampon pour placer une instruction dans la partie de mémoire à partir de laquelle il peut détourner l'exécution du programme.

En tenant compte de cette définition légèrement simplifiée de la saturation de tampon, nous allons décrire ci-dessous quatre fonctions de Visual Studio 2005, conçues pour vous aider à repérer les failles de sécurité potentielles de votre code et à empêcher un intrus de les exploiter.

Analyse du code /analyze

L'analyse du code est une fonction de Visual Studio 2005 Team Edition for Software Developers. Cette fonction est dérivée d'un utilitaire initialement employé en interne par Microsoft et appelé PREfast, qui a été publié avec le DDK (Device Driver Kit) de Microsoft. La fonction d'analyse du code analyse le code source C et C++, en examinant tous les chemins d'exécution possibles de chaque fonction et en simulant chacun d'entre eux afin de détecter les problèmes éventuels. Dans la mesure où cette fonction n'exécute pas de code, elle ne peut pas trouver toutes les erreurs possibles. Elle détecte cependant des erreurs susceptibles d'être ignorées par le compilateur. L'analyse du code détecte des problèmes dans des domaines tels que les types de casts et de données, les performances, la sécurité, les expressions, les boucles, l'allocation de la mémoire, les chaînes de format, les valeurs de retour et la gestion des exceptions.

Lorsque la fonction d'analyse du code est activée dans Visual Studio 2005 Enterprise Edition, les erreurs détectées s'affichent dans la fenêtre Error List (Liste d'erreurs). Vous pouvez activer l'analyse du code à l'aide de l'option /analyze (analyser) ou en affectant à l'option Enable code analysis for C/C++ (Activer l'analyse du code pour C/C++) la valeur Yes(/analyze) (Oui(/analyser)) dans la section General (Général) du nœud Code Analysis dans la boîte de dialogue Pages de propriétés (voir figure 1).

Figure 1. Règles de sécurité disponibles via l'analyse du code

Application Verifier

Application Verifier (AppVerifier) était initialement intégré à l'Application Compatibility Toolkit. AppVerifier regroupe une série de tests d'analyse d'exécution permettant de détecter les erreurs d'exécution dans les programmes. Les erreurs détectées par Application Verifier concernent principalement les problèmes de compatibilité, de stabilité et de sécurité. Elles appartiennent à l'une des trois catégories suivantes : vérification des handles, vérification des boucles et vérification des tas (heaps). Les paramètres propres à AppVerifier se trouvent dans le nœud Application Verifier de la boîte de dialogue Pages de propriétés.

Pour lancer Application Verifier, dans le menu Déboguer, cliquez sur Start with Application Verifier (Démarrer avec Application Verifier). Application Verifier utilise des arrêts pour fournir des informations lorsque des erreurs sont détectées dans les différentes couches de vérification. Les développeurs peuvent configurer Application Verifier de manière qu'il exécute des opérations spécifiques lors de l'apparition d'un arrêt : arrêt sur les erreurs et consignation des erreurs, par exemple. La figure 2 indique les paramètres d'Application Verifier dans la boîte de dialogue Pages de propriétés.

Figure 2. Options d'arrêt avec Application Verifier

Contrôle de sécurité du tampon /GS

L'option de contrôle de sécurité du tampon du compilateur Visual C++ (/GS) est conçue pour éviter que du code malveillant n'exploite les saturations de tampon dans les applications. Ces saturations sont à l'origine de la plupart des failles de sécurité du code. L'option /GS fonctionne en configurant une valeur cryptée (appelée parfois « canari ») à la fin d'un tampon. Cette valeur est vérifiée pendant l'exécution du code et, si elle a changé, l'exécution du programme est interrompue et une exception de sécurité est générée.

L'option /GS n'empêche pas la saturation du tampon, mais elle assure une réelle protection contre le piratage possible du code en interrompant l'exécution du programme.

Bibliothèques CRT sécurisées

Les bibliothèques CRT sécurisées sont le résultat d'un remaniement des bibliothèques C et C++ standard. Elles sont conçues pour améliorer la sécurité des applications compilées avec Visual C++, en ajoutant des contrôles de tampon adaptés aux fonctions connues pour être vulnérables aux attaques et pour déprécier une fonction d'exécution sensible.

Ces modifications concernent les principales bibliothèques de programmation, notamment CRuntime Library (CRT), Standard C++ Library (SCL), Microsoft Foundation Classes (MFC) et Active Template Library (ATL). Dans le cadre de ce remaniement, les bibliothèques MFC et ATL ont été revues afin d'utiliser les fonctions de Safe C Library. En conséquence, la recompilation des applications MFC et ATL avec Visual C++ 2005 procure automatiquement certains des avantages des bibliothèques CRT sécurisées.

Pour toute information sur les bibliothèques CRT sécurisées, reportez-vous à l'article de MSDN Magazine, Repel Attacks on Your Code with the Visual Studio 2005 Safe C and C++ Libraries (en anglais) de Martyn Lovell (responsable du développement de Microsoft Visual C++).

Améliorations de la sécurité pour le code managé

Le code managé suscite des préoccupations légèrement différentes en matière de sécurité mais, en raison du mode de gestion de la mémoire dans le Common Language Runtime (CLR), la saturation de tampon est moins problématique. Dans cette section, j'examinerai les fonctions de sécurité de Visual Studio 2005 les plus intéressantes pour les développeurs qui écrivent des applications managées.

FxCop

Les développeurs utilisent l'outil FxCop autonome depuis des années pour vérifier la conformité des assemblys avec les instructions de conception .NET Framework. Cet outil est aujourd'hui intégré à Visual Studio 2005.

FxCop fonctionne en analysant le flux d'instructions MSIL et le graphe d'appel afin de détecter les violations des règles spécifiées par l'utilisateur, habituellement dans le respect des instructions de conception .NET Framework : règles en matière de sécurité, de conception de bibliothèques, de globalisation, d'interopérabilité, de facilité de maintenance, d'affectation de noms, de performances, de fiabilité, d'utilisation, etc.

Dans Visual Studio 2005, la fonctionnalité FxCop est accessible via l'onglet Code Analysis (Analyse du code) de la page des propriétés du projet relative à l'application managée. La figure 3 décrit certaines des règles de sécurité que vous pouvez examiner dans le cadre de votre analyse.

Figure 3. Accès aux règles d'analyse du code dans Visual Studio 2005.

Vous activez l'analyse du code en activant la case à cocher Enable Code Analysis (Activer l'analyse du code) dans la page des propriétés de l'analyse du code relative au projet managé. Cette opération génère des avertissements supplémentaires dans la fenêtre Error List (Liste d'erreurs) de Visual Studio 2005. Vous pouvez diminuer le nombre d'éléments figurant dans la liste en choisissant d'analyser seulement les séries de règles qui vous intéressent, par exemple les règles relatives à la sécurité et à la fiabilité.

Sécurité d'accès au code/moindre privilège

Les applications .NET Framework sont exécutées selon un modèle de sécurité appelé Sécurité d'accès au code. Il s'agit d'un modèle fondé sur des preuves, dans lequel le privilège de sécurité est accordé sur la base de facteurs tels que l'emplacement et la signature de l'assembly. Ces facteurs sont comparés aux stratégies définies au niveau de l'utilisateur, de la machine ou du domaine. Les stratégies associées aux différents facteurs permettent aux applications de s'exécuter avec des autorisations très spécifiques qui leur sont accordées. Ce concept est appelé « confiance partielle ».

L'une des difficultés liées au déploiement d'applications partiellement sécurisées concerne le test de ces applications à mesure de leur développement. En principe, le développeur est totalement autorisé à exécuter l'application qu'il est en train d'écrire. Toutefois, pour connaître le comportement de cette application lorsqu'elle sera exécutée sur un intranet ou sur Internet, il doit la déplacer pour la tester dans ces conditions. À cet égard, Visual Studio 2005 apporte une aide précieuse en proposant de nombreux outils et fonctions que les développeurs peuvent utiliser pour tester et déboguer leurs applications à partir de l'IDE afin de s'assurer que, une fois déployées, elles fonctionneront correctement avec le niveau de confiance qui leur est accordé d'après la stratégie en vigueur.

Déploiement avec ClickOnce

ClickOnce est une technologie intégrée à Visual Studio 2005 qui, pour les développeurs, facilite l'écriture d'applications qui seront déployées pour des utilisateurs disposant de comptes à autorisations limitées. Ces applications peuvent s'exécuter localement, à partir d'un partage intranet ou d'un lien HTTP sur une page Web. Les applications exécutées à partir d'emplacements réseau sont mises en cache et exécutées localement, mais avec les autorisations accordées seulement à l'emplacement dans lequel elles résident réellement. Lorsque le développeur déploie la nouvelle version d'une application vers un emplacement réseau, ce dernier est d'abord vérifié lorsque l'utilisateur lance l'application et le cache est mis à jour.

Visual Studio 2005 permet aux développeurs de tester l'exécution de ces applications partiellement sécurisées à partir de l'IDE. Cela vous fait gagner du temps et vous simplifie considérablement la tâche pour créer et déployer des applications avec CAS.

Débogage dans la zone

Pour tirer parti de ClickOnce, il est important que les développeurs puissent tester facilement leurs applications avec le jeu d'autorisations qui sera accordé à l'application, une fois qu'elle sera déployée. Grâce à la fonction Debug in Zone (Débogage dans la zone), les développeurs peuvent spécifier le niveau de confiance dont l'application aura besoin à mesure qu'ils la conçoivent et la déboguent. Cela permet de tester l'application telle qu'elle est déployée dans un emplacement réseau avec divers niveaux de confiance. Cette fonctionnalité est accessible via l'onglet Sécurité des pages de propriétés du projet relatives à une application managée.

Pour utiliser cette fonction, ouvrez l'onglet Securité du projet et indiquez qu'il s'agit d'une application partiellement sécurisée. Vous pouvez alors choisir la zone dans laquelle vous voulez installer votre application et spécifier les autorisations que celle-ci exigera une fois déployée. Ces paramètres sont décrits à la figure 4.

Figure 4. Spécification des autorisations de sécurité de l'application dans l'onglet Sécurité du projet.

Exceptions de sécurité améliorées pendant le débogage

Dès que vous avez défini votre zone, l'exécution de l'application génère des exceptions de sécurité pour cette zone. La nouvelle boîte de dialogue des exceptions de sécurité représentée en figure 5 vous donne une idée de ce qui peut se passer en cas d'exceptions de sécurité lors du débogage de vos applications.

Figure 5. Exception de sécurité dans Visual Studio 2005

La fenêtre Exception de sécurité ne se contente pas de vous fournir une notification. Elle présente des conseils et la procédure à suivre pour modifier l'application afin qu'elle fonctionne dans un scénario de confiance partielle. Par exemple, la classe FileIOPermission n'est pas autorisée dans la zone dans laquelle le programme de la figure 4 a été exécuté. L'une des suggestions émises pour corriger ce problème consiste à utiliser un stockage isolé pour l'application.

IntelliSense dans la zone (fonction Visual Basic)

IntelliSense dans la zone est une fonction de sécurité propre à Visual Basic. La sécurité dans la zone restreint les options offertes par IntelliSense aux seules API autorisées pour une zone spécifique. Les fonctions indisponibles dans la zone en cours sont en grisé. Les développeurs écrivant des applications partiellement sécurisées peuvent ainsi ne sélectionner que les API connues pour être autorisées dans une zone particulière.

PermCalc

PermCalc est une application autonome, utilisée par les développeurs .NET afin d'analyser les autorisations nécessaires pour exécuter correctement une application managée. Cette fonctionnalité, désormais ajoutée à Visual Studio 2005, est accessible d'un seul clic sur l'onglet Sécurité de la fenêtre des propriétés du projet relative à une application managée.

Pour utiliser l'application PermCalc dans l'IDE, définissez la zone d'installation de votre application, puis cliquez sur le bouton Calculate Permissions (Calculer les autorisations). Si votre application exige plus d'autorisations qu'il n'y en a de disponibles pour la zone, le mot « Include » (Inclure) s'affiche dans la colonne Settings (Paramètres) du tableau des autorisations de la page (voir figure 6). Ces éléments sont marqués d'un symbole Attention pour indiquer que l'autorisation requise n'est pas disponible par défaut dans la zone sélectionnée. Si l'utilitaire PermCalc détermine que l'application exige une confiance totale pour s'exécuter correctement, un message vous en informe.

Figure 6. Le bouton Calculate Permissions (Calculer les autorisations) détermine les autorisations qui seront exigées par une application pour qu'elle s'exécute correctement.

Autres améliorations de la sécurité

Dans Visual Studio 2005, il existe plusieurs nouvelles fonctions de sécurité qui concernent à la fois les projets natifs et les projets managés. Nous examinerons ensuite le développement et les tests à moindre privilège tels qu'ils s'appliquent à la sécurité.

Développement et débogage à moindre privilège

L'une des manières dont les utilisateurs d'ordinateurs peuvent empêcher des logiciels malveillants d'affecter leurs systèmes est de réduire le niveau de privilège lié à leurs exécutions. Un logiciel malveillant exécuté par un utilisateur disposant de privilèges administratifs a accès à toutes les parties de la machine. D'un point de vue de sécurité générale, il faut absolument éviter les exécutions en tant qu'administrateur.

Par ailleurs, les développeurs connectés en tant qu'administrateurs ne voient pas les problèmes que les utilisateurs ayant de moindres privilèges rencontrent lorsqu'ils exécutent l'application. Par exemple, une application qui écrit dans le dossier Program Files ou System fonctionne de façon transparente pour un utilisateur ayant des privilèges administratifs. En revanche, l'accès en écriture à ces dossiers est limité pour les comptes connectés en tant qu'Utilisateur, de sorte que les tentatives effectuées par l'application pour enregistrer des données dans ces emplacements échouent.

Avec les versions antérieures de Visual Studio, il était difficile d'écrire et de déboguer des applications en utilisant des comptes avec des privilèges réduits car Visual Studio s'exécute mieux sous des comptes à privilèges élevés. Avec Visual Studio 2005, cette situation a changé. Visual Studio 2005 s'exécute proprement sous un compte Utilisateur et vous pouvez développer et déboguer les applications de cette manière aussi facilement que vous pouviez le faire auparavant en tant qu'Administrateur ou Utilisateur du débogueur.

N'oubliez pas cependant que, même avec Visual Studio 2005, vous pouvez rencontrer des problèmes liés aux compléments qui sont conçus pour fonctionner avec des comptes à privilèges plus élevés. Si vous êtes confronté à ce type de situation, signalez aux fournisseurs des compléments que leurs produits exigent un privilège plus élevé qu'il n'est probablement nécessaire. Dans la plupart des cas, si vous redirigez les requêtes de stockage ou de registre vers l'emplacement approprié, le complément peut s'exécuter correctement.

Fonctions de test

La recherche de problèmes de sécurité constitue une partie importante de l'écriture de votre application en vue d'utiliser celle-ci dans un environnement connecté. Visual Studio 2005 Team System intègre de nombreux outils de test qui vous aident à développer des applications plus sécurisées.

Test d'unités

Les tests d'unités sont principalement utilisés pour s'assurer que la valeur de retour d'une méthode est celle attendue, compte tenu des valeurs transmises à la méthode. Lorsque vous traitez des données utilisateur, il est important de vérifier qu'elles sont telles que prévu, notamment en ce qui concerne leur type et leur longueur, ces deux facteurs devant être vérifiés avant le traitement des données. Vous pouvez utiliser des tests d'unités pour envoyer des données aléatoires à une fonction et vous assurer que l'application les gère comme il se doit et qu'elle se comporte de manière appropriée.

La couverture du code peut également être activée dans vos tests d'unités. Cette couverture permet de garantir que le code contenu dans l'application est testé et de détecter le code peu utilisé, tel qu'un gestionnaire d'exceptions. Le code ne faisant pas partie du flux normal d'une application peut encore être vulnérable aux attaques. Il est arrivé souvent que des intrus exploitent du code conçu pour s'exécuter quand le flux normal est interrompu.

Visual Studio 2005 incorpore de nombreux outils de test qui vous permettent de créer des tests d'unités. Vous pouvez créer un test d'unités manuellement dans Visual C++, Visual C# ou Visual Basic à partir de la boîte de dialogue Add New Test (Ajouter un nouveau test), représentée en figure 7.

Figure 7. Création d'un test d'unités à partir de la boîte de dialogue Add New Test (Ajouter un nouveau test) dans Visual Studio 2005

Parallèlement à la création manuelle de tests d'unités, vous pouvez créer des tests à l'aide de l'Assistant de tests d'unités. Vous découvrirez ainsi comment fonctionnent ces types de tests et disposerez d'un point de départ pour vos propres tests.

Tests sous contraintes (charge)

Les tests de charge sont importants car ils vous aident à déboguer des scénarios tels que des attaques potentielles de refus de service qui peuvent être lancées contre vos applications Web. Le modèle Load Test (Test de charge) de la boîte de dialogue Add New Test (Ajouter un nouveau test) appelle l'Assistant de test de la nouvelle charge représenté en figure 8. Parallèlement à l'exécution de tests de charge pour les situations que votre application est susceptible de rencontrer, vous pouvez utiliser cet outil pour tester les scénarios anormaux. Pour ce faire, envoyez un très grand nombre de requêtes à votre application pour voir comment elle se comporte face à la charge. En observant soigneusement votre application, vous pourrez reconnaître une attaque et prévoir une réponse pour l'un de ces types d'attaques, si nécessaire.

Figure 8. Préparation d'un test de charge dans Visual Studio 2005

Conclusion

Cet article vous a donné un bref aperçu de certaines fonctions de sécurité qui font de Studio 2005 un nouvel outil indispensable pour les développeurs. Que vous écriviez un petit utilitaire ou un système stratégique de grande envergure, la sécurité des machines de vos clients et celle des applications que vous créez doivent être une priorité majeure. Avec les nouveaux outils intégrés à Visual Studio 2005, vous pouvez écrire, tester et déployer des applications sécurisées plus facilement que jamais.

Brian Johnson est responsable de programme pour MSDN. Il est en charge du contenu de Visual Studio, de Visual C++, de la sécurité et des centres de développement .NET Framework sur MSDN.