Exporter (0) Imprimer
Développer tout

Amélioration de la sécurité dans le .NET Framework 2.0

Par Rudolph Araujo et Shanit Gupta, Foundstone Professional Services

Vue d'ensemble de quelques-uns des changements majeurs en termes de sécurité dans Microsoft .NET Framework 2.0 et Visual Studio 2005 (41 pages imprimées).

Cet article concerne :

  • .NET Framework 2.0

  • Visual Studio 2005

  • Sécurité

Retrouvez l’article en langue anglaise en cliquant ici.

Sur cette page

Introduction Introduction
Développement en confiance partielle Développement en confiance partielle
Sécurité d'accès au code Sécurité d'accès au code
ASP.NET ASP.NET
C/C++ C/C++
Visual Basic .NET Visual Basic .NET
Cryptographie Cryptographie
Code géré Code géré
Prise en charge des outils Prise en charge des outils
Conclusion Conclusion
Annexe de références Annexe de références
À propos des auteurs À propos des auteurs
À propos de Foundstone Professional Services À propos de Foundstone Professional Services

Introduction

Les développeurs créent des applications afin d'atteindre un certain nombre d'objectifs. La sécurité est généralement considérée comme une surcharge. L'intégration de la sécurité dans les applications représente généralement du temps, de l'argent et n'est pas une opération directe. Cependant, dans un contexte de développement d'applications sécurisées, les développeurs doivent être soucieux de créer des applications sûres, car il s'agit d'une exigence des entreprises. En outre, à mesure que les exigences de compatibilité sont devenues plus contraignantes, les équipes de développement ont commencé à réaliser que la création d'applications sécurisées n'est plus facultative, car la protection des informations client sensibles est une fonction indispensable dans les environnements numériques d'aujourd'hui. Par le passé, la sécurité était l'affaire de quelques personnes, considérées comme des « gourous de la cryptographie », dont le rôle était de superposer la sécurité sur le code existant juste avant la mise en production ou pire, après la découverte des vulnérabilités. En fait, de nombreux développeurs et organisations informatiques partent du principe que la cryptographie (et plus particulièrement SSL) est le « bouton rouge » qui représente la solution à tous les problèmes de sécurité. Les fonctionnalités de sécurité n'étaient pas intuitives dans les langages et environnements, et n'étaient pas simples à utiliser. Heureusement, grâce à certains nouveaux environnements, tels que Java et Microsoft .NET, ce problème est devenu marginal. Ces environnements tentent de permettre aux développeurs de faire plus facilement « les bons choix », tout en rendant plus difficile de faire les mauvais choix. Le .NET Framework 2.0 et Visual Studio 2005 tentent un saut significatif afin de permettre aux développeurs d'intégrer facilement les principes du développement sécurisé des applications. Les nouvelles versions du Framework et de l'environnement de développement offrent aux équipes de développement logiciel plusieurs nouveaux outils, fonctionnalités et aides afin de permettre aux programmeurs d'intégrer les fonctionnalités de sécurité avec un stress minimal.

Dans ce document, nous allons étudier les nouvelles fonctionnalités de sécurité du .NET Framework 2.0 et de Visual Studio 2005. La suite de cet article est organisée en plusieurs catégories, afin de permettre aux développeurs de sélectionner le contenu qui les concerne le plus :

  • Développement en confiance partielle

  • Sécurité d'accès au code

  • ASP.NET

  • C/C++

  • Visual Basic .NET

  • Cryptographie

  • Code géré

  • Prise en charge des outils

Chaque section ci-dessous offre une courte description des fonctionnalités nouvelles et améliorées du Framework mis à jour, ainsi que des liens vers davantage d'informations. Le lecteur est fortement invité à suivre ces liens pour les sujets intéressants, car nombre d'entre eux offrent également des exemples de code et des scénarios d'utilisation plus détaillés.

Développement en confiance partielle

Dans le .NET Framework version 1.x, il était difficile, voire impossible, de créer des applications de confiance. Cela tenait à différentes raisons, notamment l'absence d'une prise en charge complète des bases de données : les classes de clients SQL n'étaient pas accessibles en confiance partielle dans les versions antérieures du .NET Framework, il était difficile de déboguer les scénarios de confiance partielle, et il manquait des informations claires et précises sur ce qui fonctionnait et ce qui ne fonctionnait pas dans ces scénarios. La plupart des développeurs créaient ainsi leurs applications pour une exécution en confiance totale, ce qui leur évitait d'avoir à gérer les complexités de la confiance partielle. La confiance partielle est un mécanisme extrêmement efficace pour appliquer le principe du moindre privilège. Elle permet de limiter les privilèges d'un assembly en fonction des stratégies de sécurité d'accès au code, ainsi que des autorisations de l'utilisateur dans le contexte duquel l'application s'exécute.

Avec .NET 2.0, il est devenu beaucoup plus facile de créer des applications riches qui peuvent continuer de fonctionner dans une zone à confiance partielle. Dans cette section, nous allons décrire quelques-unes de ces nouvelles fonctionnalités et améliorations spécialement conçues pour résoudre le problème mentionné.

  • Exception de sécurité améliorée : Avec l'objet SecurityException (exception de sécurité) amélioré dans le .NET Framework 2.0, le développeur est équipé des propriétés qui lui permettent de trouver la cause précise du problème de sécurité. L'objet SecurityException amélioré est intégré dans l'environnement IDE et est accompagné de la cause détaillée de l'exception. Il fournit également la procédure permettant de résoudre le problème. Les nouvelles propriétés de l'objet .NET Framework SecurityException sont répertoriées ci-dessous :

    Tableau 1

    Nom

    Type

    Description

    Action

    SecurityAction

    Action de sécurité pour laquelle la vérification de sécurité a échoué

    Demanded

    Object

    Autorisation, ensemble d'autorisations ou ensembles d'autorisations ayant demandé et déclenché l'exception

    DenySetInstance

    Object

    Si une trame de pile Deny a provoqué l'échec de l'exception de sécurité, cette propriété contient cet ensemble ; à défaut, elle contient NULL.

    FailedAssemblyInfo

    AssemblyName

    Nom de l'assembly ayant provoqué l'échec de la vérification de sécurité.

    FirstPermissionThatFailed

    IPermission

    Première autorisation de PermissionSet (ou PermissionSetCollection) qui n'a pas réussi la vérification de sécurité.

    Method

    MethodInfo

    Méthode dans laquelle se trouvait l'assembly lorsqu'il a rencontré la vérification de sécurité ayant déclenché l'exception. Si une trame de pile PermitOnly ou Deny a échoué, elle contient la méthode ayant placé la trame PermitOnly ou Deny sur la pile.

    PermitOnlySetInstance

    Object

    Si la trame de pile ayant provoqué l'exception de sécurité comportant un ensemble d'autorisations PermitOnly, cette propriété le contient ; à défaut, elle contient NULL.

    Url

    String

    URL de l'assembly pour lequel la vérification de sécurité a échoué.

    Zone

    SecurityZone

    Zone de l'assembly pour lequel la vérification de sécurité a échoué.

    Référence :
    classe SecurityException dans la bibliothèque de classes du .NET Framework

  • Débogage dans la zone : Les développeurs procèdent généralement au développement et au débogage de leurs programmes via un ordinateur local, et donc à partir de l'environnement le plus sécurisé : généralement en confiance totale. Pour tester et déboguer la façon dont l'application fonctionne lors de l'exécution à partir d'un intranet ou d'Internet, le développeur doit toujours déplacer l'application vers un autre système et la tester dans ces conditions.

    Pour aider les développeurs à simplifier leurs tests, la fonctionnalité Débogage dans la zone leur permet d'exécuter le code géré dans une boîte avec des autorisations personnalisées. Cela permet à un développeur d'émuler le comportement du code tel qu'il est vu par les utilisateurs. Les développeurs peuvent donc déboguer l'application comme si elle s'exécutait à partir d'Internet, de l'intranet ou de zones locales de l'ordinateur. Dans la plupart des cas, le développeur peut toujours sélectionner l'un de ces environnements d'exécution standard pour l'application. Cependant, lorsque le développeur souhaite personnaliser l'environnement, il peut également utiliser des autorisations d'accès fin. Cela permet aux développeurs de déboguer le code comme s'il s'exécutait à partir d'une zone spécifique ou dans une stratégie de sécurité d'accès au code définie. Par conséquent, les développeurs peuvent détecter très tôt les violations et en savoir plus sur la boîte d'exécution offerte par chacune des zones.

    Référence :
    Nouvelles fonctionnalités de sécurité de Visual Studio 2005

  • PermCalc : Dans de nombreux cas, la fonctionnalité de l'application reste relativement statique. Cela est particulièrement vrai pour les applications de type métier. Il existe généralement un ensemble bien défini de fonctionnalités que le code doit fournir pour être utile et satisfaire à ses objectifs. Une fonctionnalité utile consiste à trouver l'ensemble minimal d'autorisations de sécurité dont l'application a besoin pour satisfaire à tous ses besoins métier. L'outil PermCalc peut atteindre cet objectif. La sortie de l'outil évalue l'ensemble minimal d'autorisations requises pour exécuter l'application. L'outil passe par les différents chemins de code de l'application, ainsi que via les bibliothèques partagées et système utilisées par l'application. Pour chaque trace de chemin de code, l'outil collecte toutes les autorisations demandées via les demandes déclaratives, les demandes de liens et les modificateurs de parcours de pile déclarative.

    Tous les états d'autorisation utilisés dans les actions de sécurité déclaratives doivent être connues lors de la compilation afin de concerner toutes les actions de sécurité déclaratives sur les assemblys d'application, si elles doivent être calculées de manière exacte. Si une demande déclarative est utilisée, l'ensemble minimal d'autorisations de chaque assembly de la pile d'appel à ce stade est mis à jour avec l'ensemble d'autorisations demandé. Si une affirmation déclarative est trouvée sur la pile d'appel simulée, seule l'intersection entre l'ensemble d'autorisations affirmé et l'ensemble d'autorisations demandé est mise à jour pour tous les assemblys au-dessus de l'affirmation sur la pile d'appel. De la même façon, si une demande de lien est trouvée, seul l'appelant sur la pile d'appel simulée au-dessus du point de la demande de lien est mis à jour avec l'ensemble d'autorisations demandé.

    La trace de chemin de code est une trace via le langage MSIL (Microsoft Intermediate Language) de chaque méthode, commençant à la méthode de point d'entrée principale de l'application. Si des actions impératives de l'ensemble d'autorisations sont trouvées dans la trace MSIL de la méthode, l'algorithme de mise à jour suivant est exécuté pour chaque assembly :

    • Si l'état d'autorisation utilisé dans la demande impérative, la demande de lien, l'affirmation, autorisation unique ou refuser peut être déterminé de manière statique, et qu'il est certain qu'il ne dépend d'aucun état disponible uniquement lors de l'exécution, l'effet d'une telle action de sécurité sur les assemblys d'application peut être déterminé et calculé pour les effets des actions de sécurité déclaratives sur l'ensemble minimal d'autorisations de tous les assemblys profilés.

    • Si l'état de l'ensemble d'autorisations utilisé dans une action de sécurité impérative ne peut pas être déterminé de manière statique, l'état non restreint de l'autorisation est utilisé, par exemple autorisation de sécurité non restreinte ou autorisations de lecture d'E/S de fichiers non restreintes. Dans certains cas, cela peut conduire à une surestimation des autorisations requises pour l'exécution d'une application. L'utilisateur peut utiliser l'option -Under afin de remplacer ce comportement par défaut.

    • S'il existe plusieurs chemins de code dans une méthode et que certains présentent des annotations d'action de sécurité différentes, l'union des demandes et l'intersection des affirmations sont utilisées, car l'outil ne peut pas déterminer quel chemin de code via une méthode sera utilisé par l'application lors de l'exécution

    Référence :
    Outil de calcul des autorisations (Permcalc.exe)

  • IntelliSense dans la zone : La fonctionnalité IntelliSense dans la zone (disponible uniquement dans Visual Basic .NET) peut être utilisée conjointement avec les stratégies de sécurité d'accès au code afin d'aider les développeurs à faire les choix appropriés concernant les API qu'ils utilisent dans leur application. Lors de l'exécution dans Visual Basic .NET, la fonctionnalité IntelliSense offre des indications visuelles afin d'indiquer aux développeurs les API qui ne sont pas disponibles dans la zone d'exécution actuelle et qui entraîneront donc une violation de la stratégie de sécurité par l'application. Par exemple, lors d'une exécution à partir de la zone Intranet local, une application peut uniquement lire la variable d'environnement « username » par défaut. La fonctionnalité IntelliSense dans la zone désigne donc visuellement toute tentative de violation de cette stratégie, par exemple les tentatives d'accès à d'autres variables d'environnement.

    Référence :
    IntelliSense propre à Visual Basic

  • API de sandboxing simple avec AppDomains : Cette fonctionnalité permet aux applications d'exécuter du code non approuvé, tel que des scripts tiers, des exécutables et des plug-ins, dans un sandbox présentant un ensemble d'autorisations restreint. Par conséquent, l'hôte peut choisir les autorisations qui doivent être accordées au code non approuvé. En particulier, la méthode qui permet ce mécanisme est une nouvelle surcharge de la méthode AppDomain.CreateDomain. De la même façon, l'introduction de la classe AppDomainManager fournit l'application d'hébergement avec un contrôle plus fin de l'ensemble d'opérations que le code hébergé est autorisé à effectuer, ainsi que de l'exécution générale de ce code.

    Listing 1

    public static AppDomain CreateDomain ( 
    string friendlyName, 
    Evidence securityInfo, 
    AppDomainSetup info, 
    PermissionSet grantSet, 
    params StrongName[] fulltrustAssemblies )
    

    Référence :
    Méthode AppDomain.CreateDomain (String, Evidence, AppDomainSetup, PermissionSet, StrongName[])

  • Autorisations de confiance partielle : Dans le .NET Framework 2.0, l'accès à SQL Server est disponible au niveau de confiance moyen, car le fournisseur de données .NET Framework pour SQL Server n'exige plus une confiance totale. Les classes SQL Client sont ainsi disponibles pour les applications de confiance moyenne, lesquelles autorisent à leur tour les développeurs en confiance partielle à accéder aux installations Microsoft SQL Server. De la même façon, les applications de confiance moyenne peuvent désormais s'abonner afin de recevoir des notifications du serveur SQL, car l'autorisation SQLNotification est également disponible en confiance partielle. Le fournisseur géré par OLE DB ne nécessite plus la confiance totale de ses appelants ; ils nécessitent uniquement l'autorisation OleDbPermission. Pour accéder à une source de données OLE Db à partir d'une confiance partielle, une stratégie de confiance personnalisée est requise, accordant l'autorisation OleDbPermission à l'application.

    Dans la version 2.0, SmtpPermission est disponible avec les niveaux de confiance Total, Élevé et Moyen. Cela permet aux applications d'envoyer du courrier électronique. Les applications n'ont plus besoin d'une confiance totale pour accéder au journal des événements. Une stratégie de confiance personnalisée peut être créée, qui accordera au code l'autorisation EventLogPermission.

Sécurité d'accès au code

Les applications créées dans le .NET Framework permettent l'accès aux ressources sur la base de la preuve présentée par le code. Ce modèle est appelé Sécurité d'accès au code. Ce modèle de sécurité est très différent du modèle traditionnel, dans lequel les autorisations affectées à une application étaient basées sur les privilèges de l'utilisateur ayant ouvert une session. La preuve peut être fournie sous la forme d'origine de l'application et de signatures numériques. Chaque système peut être configuré sur la base du domaine d'application, de l'utilisateur, de l'ordinateur et de la stratégie d'entreprise. En fonction de ces paramètres de stratégie, l'application peut se voir accorder ou refuser l'autorisation sur certains ensembles de ressources.

Le modèle Sécurité d'accès au code est encore amélioré dans le .NET 2.0 Framework. Il offre un grand nombre de nouvelles fonctionnalités et améliore nombre des fonctionnalités existantes, tout en tentant de rendre le travail le plus facile et le plus intuitif possible pour un développeur qui exploite ce modèle. Cela inclut donc quelques outils nécessaires pour l'application de stratégies.

  • GAC confiance totale : Contrairement aux versions 1.* et Whidbey bêta 1, il est important de noter que le GAC est explicitement en confiance totale dans la version 2.0, et non par effet secondaire lié à la présence sur l'ordinateur local. Whidbey bêta 2 accorde aux assemblys du GAC une confiance totale, indépendamment de la façon dont la stratégie de sécurité est configurée pour eux. Cependant, la sécurité déclarative au niveau assembly continue de fonctionner normalement. Si l'assembly décide d'utiliser RequestRefuse ou RequestOptional même lorsqu'il est présent dans le GAC, l'ensemble accordé n'est pas en confiance totale. Bien entendu, tout assembly placé dans le GAC démarre en confiance totale, quelle que soit la stratégie définie. Cette mise à jour nécessite à l'évidence que les utilisateurs soient beaucoup plus prudents concernant l'importation d'un assembly non sécurisé dans GAC.

    Référence :
    Blog de sécurité .NET

  • Confiance totale signifie confiance totale : Dans .NET 2.0, tout code auquel une confiance totale est accordée ne bénéficie plus d'une protection CAS. Cela signifie que les développeurs ne peuvent plus utiliser Autorisations d'identité pour restreindre le code auquel une confiance totale est accordée.

    • Les autorisations d'identité dans n'importe quel état deviennent un sous-ensemble de l'ensemble d'autorisations Non restreint. Cela signifie que la demande d'autorisations d'identité est traitée avec succès par n'importe quel code en confiance totale.

    • Logique définie pour les changements IdentityPermissions. Cela permet aux développeurs d'effectuer des opérations logiques telles que l'union et l'intersection pour les autorisations d'identité.

    • Les demandes LinkDemands sont optimisées en confiance totale. Toute demande LinkDemand d'autorisation d'identité ou CAS est traitée en confiance totale. Un changement risquant de poser un problème pour l'application est un changement dans lequel l'intérêt des performances avantage les demandes LinkDemands non CAS ignorées en confiance totale.

    Référence :
    Weblog d'Eugene Bobukh

  • Transparence de la sécurité : Le code transparent est du code qui abandonne volontairement sa capacité à élever les autorisations de la pile d'appel. En raison de ces restrictions, le code transparent s'exécute soit avec l'ensemble d'autorisations qui lui a été accordé, soit avec l'ensemble d'autorisations accordé à ses appelants (l'ensemble le plus limité des deux). Par conséquent, le code transparent totalement approuvé s'exécute pour l'essentiel dans le même contexte de sécurité que ses appelants, car les autorisations de l'appelant sont nécessairement inférieures ou égales à la confiance totale. Cela s'avère particulièrement utile si vous souhaitez que votre assembly soit utilisé par des appelants partiellement approuvés. Cela permet de garantir que le code partiellement approuvé ne peut effectuer aucune opération qu'il n'aurait pas pu effectuer autrement. Les règles suivantes s'appliquent au code transparent :

    • Le code transparent ne peut pas affirmer que les autorisations doivent interrompre le parcours de la pile.

    • Il ne peut pas satisfaire de demande LinkDemand. À l'inverse, les demandes LinkDemands sur les API appelées par l'assembly transparent sont automatiquement converties en demandes complètes.

    • Le code transparent ne peut pas utiliser automatiquement du code non vérifiable, même avec l'autorisation SkipVerification. En revanche, toute méthode contenant du code non vérifiable présente une demande d'autorisation UnmanagedCode injectée.

    • De la même façon, les appels de méthodes P/Invoke décorées avec SuppressUnmanagedCodeAttribute entraînent une demande complète de UnmanagedCode.

    Il est possible de marquer différents segments de code comme critiques pour la sécurité ou comme transparents à l'aide des attributs suivants :

    • a) [assembly: SecurityTransparent] : l'assembly complet est converti en module avec transparence de la sécurité.

    • b) [assembly: SecurityCritical] : permet à certains segments de code d'être rendus critiques. Le code critique de la sécurité doit être marqué de manière explicite. Le reste du code est considéré comme transparent pour la sécurité.

    Références :
    Blog sur la sécurité .NET : quand le contraire de transparent n'est pas opaque
    Blog sur la sécurité .NET : marquer le code comme transparent

  • ClickOnce : ClickOnce offre un modèle de déploiement de confiance afin de permettre aux utilisateurs de télécharger et d'exécuter les applications à partir de serveurs centralisés, sans nécessiter de privilèges administrateur sur l'ordinateur client. Les applications déployées avec ClickOnce sont garanties de ne pas interférer avec d'autres applications ou de ne pas endommager les données sur le système. En outre, les applications ClickOnce sont exécutées dans un contexte d'exécution sécurisé dont les autorisations sont limitées selon l'emplacement d'où provient l'application ou selon la confiance accordée à l'auteur de cette application. Il est possible de remplacer la stratégie basée sur l'emplacement par la stratégie de sécurité personnalisée sur le système qui dépend de la preuve basée sur le contenu.

  • TrustManager : Interface utilisateur par défaut de System.Windows.Forms.dll, qui permet aux utilisateurs de prendre des décisions de confiance ClickOnce concernant l'autorisation du code nécessitant des privilèges plus élevés que ceux que la stratégie et la zone actuelles sur l'ordinateur local permettent d'installer. Les gestionnaires de confiance peuvent être verrouillés et configurés afin d'autoriser uniquement les applications de certaines zones à élever les privilèges. En outre, il est possible de configurer uniquement les applications approuvées afin d'être autorisé à élever les privilèges. Une autre option consiste à déployer une licence de confiance à partir d'une autorité de licence approuvée, qui autorise les actions avec privilèges élevés sans inviter l'utilisateur.

  • ApplicationSecurityManager : Aide à déterminer et à mettre en cache les décisions d'approbation au cours du processus ClickOnce, et peut également être utilisé pour pointer vers un gestionnaire d'approbation personnalisé s'il est utilisé. Les décisions d'approbation des applications sont mises en cache dans un fichier XML accessible à l'aide de la classe ApplicationSecurityManager. Cela permet d'énumérer l'approbation des autres applications, ainsi que d'ajouter et de supprimer l'approbation des applications de sécurité.

    Références :
    ClickOnce : déploiement et mise à jour de vos projets de client intelligent à l'aide d'un serveur central
    ClickOnce et la sécurité

  • GacMembershipCondition : Une nouvelle condition d'appartenance basée sur les preuves a été ajoutée au Framework. La condition GacMembershipCondition est satisfaite par tous les assemblys installés dans le GAC. Ces assemblys présentent des autorisations de confiance totale explicites et ne sont plus liées à la stratégie de l'ordinateur local.

    Référence :
    classe GacMembershipCondition

  • CodeConnectAccess/NetCodeGroup : Ces classes sont utilisées pour contrôler la façon dont le code en cours d'exécution peut se reconnecter au site à partir duquel il a été téléchargé. Le développeur peut contrôler à la fois le protocole et le port que le code est autorisé à utiliser lors de la reconnexion au site d'origine. En outre, il est possible de créer une règle d'accès aux connexions qui s'applique lorsque le schéma d'origine n'est pas présent dans la preuve ou n'est pas reconnu. Cela permet également au développeur de créer une règle d'accès aux connexions qui s'applique lorsqu'il n'y a pas de règle d'accès avec un schéma correspondant.

    Listing 2

    public static void SetNetCodeGroupAccess() 
    { 
    const string userPolicyLevel = "User"; 
    // Find the User policy level. 
    PolicyLevel userLevel = null; 
    System.Collections.IEnumerator policyHirarchy = System.Security.SecurityManager.PolicyHierarchy(); 
    while(policyHirarchy.MoveNext()) 
    {
       userLevel = (PolicyLevel) policyHirarchy.Current;
       if(userLevel.Label == userPolicyLevel ) 
       { 
          break; 
       } 
    } 
    if (userLevel.Label != userPolicyLevel) throw new ApplicationException
    ("Could not find User policy level."); 
    IMembershipCondition membership = new UrlMembershipCondition(@"http://www.foundstone.com/*");
    NetCodeGroup codeGroup = new NetCodeGroup(membership);
    
    // Delete default settings. 
    codeGroup.ResetConnectAccess(); 
    
    // Create an object that represents access to the HTTPS scheme and 
    // default port.    
    CodeConnectAccess httpsAccess = new CodeConnectAccess(Uri.UriSchemeHttps,
    CodeConnectAccess.DefaultPort); 
    
    // Create an object that represents access to the origin scheme and 
    // port. 
    CodeConnectAccess originAccess = CodeConnectAccess.CreateOriginSchemeAccess
    (CodeConnectAccess.OriginPort); 
    
    // Add connection access objects to the NetCodeGroup object. 
    codeGroup.AddConnectAccess(Uri.UriSchemeHttp, httpsAccess); 
    codeGroup.AddConnectAccess(Uri.UriSchemeHttp, originAccess); 
    
    // Enter the name and description information
    codeGroup.Name = "ContosoHttpCodeGroup"; codeGroup.Description = 
    "Code originating from Foundstone.com can connect back using HTTPS."; 
    
    // Add the code group to the User policy's root node. userLevel.RootCodeGroup.AddChild(codeGroup); 
    
    // Save the changes to the policy level. System.Seclurity.SecurityManager.SavePolicy(); 
    }
    

    Références :
    Classe CodeConnectAccess
    Classe NetCodeGroup

  • Autorisations de sécurité d'accès au code : Un certain nombre d'autorisations de sécurité d'accès au code ont été ajoutées au Framework. Certaines de ces nouvelles autorisations sont énumérées dans le tableau ci-dessous :

    Tableau 2

    Autorisation

    Description

    Référence

    SmtpPermission

    Disponible jusqu'à la confiance moyenne et permet l'accès à la classe SmtpClient pour accéder à un serveur SMTP

    Classe SmtpPermission

    NetworkInformationPermission

    Contrôle l'accès aux informations et statistiques réseau à partir de l'ordinateur local

    Classe NetworkInformationPermission

    StorePermission

    Contrôle l'accès accordé au code sur le magasin de certificats contenant les certificats X.509.

    Classe StorePermission

    DataProtectionPermission

    Contrôle l'accès aux classes DPAPI gérées pour le cryptage de la mémoire et du stockage

    Classe DataProtectionPermission

    KeyContainerPermission

    Contrôle l'accès au conteneur principal et permet aux développeurs de proposer des applications avec un accès limité aux principaux conteneurs

    Classe KeyContainerPermission

  • HostProtectionResource : permet à une classe ou une méthode d'informer le runtime sur les catégories de fonctionnalités potentiellement néfastes pour l'hôte, l'application ou les threads. Par exemple, l'instruction ci-dessous illustre l'utilisation de l'énumération HostProtectionResource avec l'attribut HostProtectionAttribute. Nous utilisons les indicateurs d'énumération afin d'indiquer que la méthode expose l'état partagé qui peut être partagé par plusieurs threads, et que l'application expose également une interface utilisateur.

    Listing 3

    [HostProtectionAttribute(Resources = HostProtectionResource.SharedState
        |HostProtectionResource.UI)]
    

    Référence :
    énumération des ressources de protection de l'hôte

  • Autorisations personnalisées : les classes d'autorisation personnalisées ne doivent plus nécessairement résider dans le GAC dans la nouvelle version du Framework. Dans la version 2.0, la sécurité déclarative est traitée lors de l'exécution et non lors de la compilation, comme c'était le cas dans la version 1.x. Étant donné que les compilateurs version 1.x devaient accéder aux attributs de sécurité et que leur AppBase était définie sur le chemin du compilateur (en général le répertoire Framework), ils ne pouvaient pas trouver les classes, sauf si elles résidaient dans le cache d'assembly global (GAC, Global Assembly Cache). Étant donné que les compilateurs .NET 2.0 n'instancient pas les classes de sécurité déclaratives, cela ne pose pas de problème si elles ne se trouvent pas dans le GAC. Si l'assembly avec les classes d'autorisation se trouve près de l'application en cours d'exécution, lorsque le runtime peut trouver les attributs lorsqu'il a besoin de les instancier.

  • CASPol : si les versions 1.0 et 1.1 de CASPol offraient un commutateur permettant de désactiver le système de sécurité du CLR, dans la version 2.0, la sécurité ne peut être désactivée que si le processus CASPol reste actif. Lorsque l'exécution du processus CASPol se termine, la sécurité est rétablie dans l'état « actif ». Même un arrêt anormal du processus CASPol rétablit la sécurité dans cet état sécurisé.

ASP.NET

Les nouvelles fonctionnalités de sécurité d'ASP.NET 2.0 aident les développeurs de l'application à créer et à gérer les comptes utilisateur et le contrôle d'accès basé sur les rôles personnalisés dans une application Web. Le Framework présente des fonctionnalités pour concevoir et implémenter les contrôles d'authentification et d'autorisation, ce qui supprime la nécessité pour les développeurs d'écrire du code personnalisé pour ces fonctionnalités dans chaque application. Outre les contrôles de sécurité standard, le nouveau Framework offre également un mécanisme puissant pour faciliter la tâche des administrateurs qui gèrent l'application Web. Cela est effectué avec l'outil d'administration de site Web, qui est un ensemble de pages ASP.NET prédéfinies. Cet outil ne nécessite pas de connaissances de programmation de la part des administrateurs d'applications Web. Vous trouverez ci-dessous des détails sur chacune des fonctionnalités importantes :

  • Appartenance : ASP.NET 2.0 contient une fonctionnalité d'appartenance qui réduit sensiblement la quantité de code que vous devez écrire lors de l'authentification des visiteurs auprès de votre application. Il limite la nécessité de gérer le stockage physique des informations de nom d'utilisateur et de mot de passe. Il offre également une interface utilisateur afin de gérer l'appartenance à l'application, ainsi qu'à un groupe de contrôles de sécurité prenant en charge l'authentification, la récupération de mot de passe et l'état d'ouverture de session. Les détails de configuration sont stockés dans le fichier web.config, lequel peut être configuré avec un Assistant permettant au développeur de configurer l'appartenance de l'application.

    Référence :
    comment spécifier l'appartenance ASP.NET

  • Contrôles de gestion des utilisateurs : La plupart des applications comportent l'ensemble standard de routines permettant de fournir les mécanismes d'authentification et d'autorisation dans l'application ; les développeurs commettent tout de même des erreurs lors de leur implémentation. Par conséquent, il est utile de fournir un ensemble standard de contrôles bien définis, sécurisés et facilement réutilisables. Les contrôles de gestion des utilisateurs fournis par ASP.NET 2.0 tentent d'effectuer simplement cette fonction. Les contrôles inclus sont les suivants :

    Tableau 3

    Nom du contrôle

    Description

    Login

    Permet à un utilisateur d'ouvrir et de fermer une session dans l'application.

    CreateUserWizard

    Fournit la page d'enregistrement standard pour l'enregistrement d'un nouvel utilisateur. La fonctionnalité peut être facilement étendue. Par exemple, un message électronique d'enregistrement avec les informations nécessaires peut être envoyé à la fin de l'enregistrement.

    PasswordRecovery

    Fournit un contrôle hautement configurable, permettant d'effectuer un ensemble d'actions lorsque l'utilisateur oublie son mot de passe. Les actions effectuées vont de l'envoi d'un message électronique avec rappel du mot de passe à l'envoi du mot de passe proprement dit en texte clair.

    ChangePassword

    Offre un moyen permettant aux utilisateurs de changer leur mot de passe. La propriété MailDefinition informe l'utilisateur une fois que le mot de passe a été mis à jour.

    LoginName

    Fournit le nom enregistré de l'utilisateur authentifié, lequel peut être affiché pour l'utilisateur dans l'application.

    LoginStatus

    Détermine l'état d'authentification de l'utilisateur et peut afficher en conséquence le lien d'ouverture ou de fermeture de session.

    LoginView

    Gère l'affichage de l'utilisateur en fonction du rôle et du privilège de l'utilisateur actuel.

  • Cryptage des fichiers de configuration : Dans le .NET Framework 2.0, les développeurs peuvent crypter les parties sensibles du fichier web.config (s'il contient un mot de passe ou des clés, par exemple) avec l'utilitaire aspnet_regiis. Le décryptage est effectué de manière transparente. Le fournisseur de configuration protégé DPAPI prend en charge les banques de niveau ordinateur et utilisateur pour le stockage des clés. Le choix du magasin varie largement selon que l'application partage ou non l'état avec d'autres applications et selon que les données sensibles doivent être rester privées pour chaque application. Si l'application est déployée dans le scénario de groupe Web, les développeurs doivent utiliser RSAProtectedConfigurationProvider pour exploiter la facilité avec laquelle les clés RSA peuvent être exportées sur plusieurs systèmes. Elle utilise la cryptographie par clé publique RSA pour permettre la confidentialité des données.

    L'exemple suivant crypte la section de la chaîne de connexion avec l'outil aspnet_regiis :

    Listing 4

    aspnet_regiis.exe -pef "connectionStrings" C:\VirtualDirectory\Path
    

    Référence :
    Procédure : cryptage des sections de configuration dans ASP.NET 2.0 avec DPAPI

  • Gestionnaire de rôles : Le gestionnaire de rôles dans la version 2.0 du Framework permet la prise en charge du contrôle d'accès basé sur les rôles (RBAC, Role-Based Access Control). La classe RoleManagerModule est utilisée pour affecter un attribut RolePrincipal à la propriété User du contexte HTTPContext actuel. Si la demande réussit, RoleManagerModule réaffecte les cookies qui contiennent à présent les informations de rôle mises en cache.

    Référence :
    classe RoleManagerModule

  • Outil d'administration des sites Web : L'outil d'administration des sites Web d'ASP.NET vous permet d'afficher et de gérer la configuration de votre site Web par l'intermédiaire d'une simple interface Web. Cet outil peut être utilisé pour créer des utilisateurs et des rôles, ainsi que pour contrôler l'accès aux dossiers et pages de l'application Web. L'outil aspnet_regiis peut être utilisé pour contrôler l'accès à l'outil d'administration des sites Web. Un exemple serait d'autoriser uniquement l'accès à l'outil d'administration sur l'ordinateur local.

    Référence :
    analyseur de cubes (objets d'aide à la décision)

  • Autorisation d'URL : Autorisation d'URL peut être utilisé pour limiter l'accès à des chemins spécifiques en les définissant dans le fichier web.config et en les mettant en correspondance avec des utilisateurs ou rôles spécifiques. Dans les versions 1.* du .NET Framework, cela peut être effectué uniquement pour les ressources contrôlées par le runtime ASP.NET, par exemple les pages .aspx. Dans le .NET Framework 2.0, cette possibilité a également été étendue aux types de fichiers non ASP.NET, par exemple .jpg ou .html.

C/C++

Le problème de sécurité le plus courant propre au code non géré est le débordement de tampon. Les débordements de tampon se produisent lorsque les données entrées dans la mémoire tamon sont plus volumineuses que la taille allouée à cette mémoire. Il en résulte l'écrasement d'autres sections de la mémoire. De cette façon, un pirate peut injecter et exécuter du code malveillant, entraînant des effets indésirables. Les nouvelles fonctionnalités de l'environnement IDE de Visual Studio offrent des mécanismes permettant de détecter et d'éliminer de nombreuses instances de cette vulnérabilité. Elles offrent également des outils permettant de mettre en évidence d'autres types d'erreur et de bogue qui seraient sinon ignorés par le compilateur.

  • Détection de débordement de tampon basé sur la pile : L'indicateur /GS peut être utilisé au cours de la compilation pour limiter certaines classes de débordements de tampon. Il peut détecter les tentatives de débordement de tampon qui remplacent l'adresse de retour : il s'agit d'une technique courante pour exploiter le code qui n'applique pas les restrictions de taille de mémoire tampon. Cela passe par l'injection de vérifications de sécurité dans le code compilé. Cet indicateur est actif par défaut, même si l'option /GS n'est pas mentionnée explicitement dans la ligne de commande du compilateur.

    Si le pirate peut provoquer un débordement des tampons locaux, il peut écraser la trame du gestionnaire d'exceptions, le pointeur de trame et l'adresse de retour de la fonction. Il s'agit pour l'essentiel d'une condition de débordement de tampon, couramment appelée collision de pile.

    Lorsque le code est compilé avec l'indicateur /GS, pour chaque appel de fonction, le prologue de la fonction extrait une valeur aléatoire à 4 octets à partir d'un emplacement prédéfini. Cette valeur aléatoire fait ensuite l'objet d'un XOR avec l'adresse de retour de la fonction appelée, et est inséré sur la pile sous l'adresse de retour. Lorsque la fonction est sur le point de se terminer, l'épilogue de la fonction exécute une nouvelle fois un XOR entre l'adresse de retour de la pile et le cookie stocké sous l'adresse de retour. Si le résultat correspond à la valeur originale stockée dans l'emplacement prédéfini, il s'agit d'une indication que l'adresse de retour n'a pas été trafiquée, et l'exécution se poursuit. Si les valeurs ne correspondent pas, le programme passe à une fonction du gestionnaire des erreurs de sécurité et quitte.

    En outre, depuis Visual C++ .NET 2003, les structures de données vulnérables et sensibles, telles que l'adresse des gestionnaires d'exceptions, ont été déplacées vers une position de la pile d'appel sous la zone où se trouvent les tampons. Cela permet d'éviter le contournement de la protection offerte par le cookie de sécurité, par exemple via la corruption des pointeurs du gestionnaire d'exceptions. Avec le déplacement de ces données vers une région sous les tampons dans la nouvelle version du compilateur, la modification de ces données avec les débordements de tampons n'est plus possible. En outre, l'éditeur de liens de Visual C++ .NET 2003 (et versions ultérieures) insère également l'adresse de tous les gestionnaires d'exceptions structurés dans l'en-tête de l'exécutable. Par conséquent, lorsqu'une exception se produit, le système d'exploitation compare l'adresse du gestionnaire d'exceptions référencé sur la pile à celui dans l'en-tête de l'exécutable. Si les deux ne correspondent pas, le gestionnaire n'est pas autorisé à s'exécuter, ce qui empêche l'exécution du code injecté arbitraire potentiel. Windows Server 2003 et Windows XP Service Pack 2 intègrent tous deux cette possibilité.

    Référence :
    /GS (vérification de la sécurité des tampons)

  • Bibliothèques SafeCRT et protection contre le débordement d'entiers : Ces bibliothèques incluent des modifications des runtimes C/C++ standard où des fonctions spécifiques avec une conception non sûre ont été trouvées. Ces fonctions sont obsolètes et ont été remplacées par de nouvelles fonctions plus sûres. Des avertissements du compilateur sont émis afin d'indiquer l'utilisation de fonctions non sûres. Des informations de débogage complémentaires sont également ajoutées lorsque cela s'avère utile. La bibliothèque a été envoyée à ANSI pour normalisation ISO.

    Le nouvel opérateur d'allocation a également été amélioré afin de détecter les débordements d'entiers lors de l'allocation de grands blocs de mémoire, généralement des tableaux d'objets. Le compilateur C++ qui sera fourni avec Visual Studio 2005 émettra le code dans l'exécutable afin de détecter ces conditions, et renverra NULL ou lèvera une exception, en fonction de la sémantique d'erreur de l'opérateur.

    Référence :
    protection contre les attaques du code à l'aide des bibliothèques Visual Studio 2005 Safe C et C++

Visual Basic .NET

L'objet My introduit dans le nouveau Framework expose des méthodes simples d'utilisation pour de nombreuses tâches.

  • Classes My : Ces classes tentent de fournir l'accès à un certain nombre de propriétés essentielles, énumérées ci-dessous, pour l'utilisateur actuellement connecté, via une interface facilement accessible et intuitive.

Tableau 4

Propriété

Description

My.User.IsAuthenticated

Renvoie vrai afin d'indiquer que l'utilisateur est authentifié, faux dans le cas contraire.

My.User.CurrentPrincipal.Identity

Obtient ou définit l'entité actuelle pour la sécurité basée sur les rôles.

My.User.IsInRole

Détermine si l'utilisateur actuel appartient à un rôle spécifié. Renvoie vrai si l'utilisateur actuel appartient au rôle spécifié ; renvoie faux dans le cas contraire.

My.User.Name

Obtient le nom de l'utilisateur actuel.

Cryptographie

La cryptographie peut facilement devenir l'aspect le plus délicat à comprendre et surtout à implémenter pour la sécurité des applications et des logiciels. La plupart des développeurs ne comprennent pas et ne souhaitent pas comprendre la signification et la spécificité des générateurs de nombres aléatoires, de la génération de clés, du cryptage, des signatures et du stockage de données sécurisé. Les développeurs apprécient les API bien définies, qu'ils peuvent utiliser pour intégrer la cryptographie afin d'offrir des fonctionnalités telles que la confidentialité, l'intégrité et la non-répudiation dans leur application. Le .NET Framework offre de nombreuses classes et méthodes de ce type, afin de faciliter le travail des développeurs. Ils suppriment l'essentiel des soucis lors de la phase d'implémentation du cycle de développement. Des ajouts significatifs ont été ajoutés aux API de cryptographie dans la nouvelle version du .NET Framework. Nous allons en étudier quelques-uns ici.

  • PKCS#7 (Public-Key Cryptography Standards) : Ces nouvelles classes permettent de signer et de crypter les messages. Les normes prennent en charge l'utilisation de certificats X.509 pour le cryptage et le décryptage de données. Le message généré est conforme à la norme S/MIME qui permet l'envoi du message par courrier électronique. En outre, la prise en charge des certificats X.509 a également été améliorée avec l'objet X509Certificate2.

    Listing 5

    . . . 
    . . . 
    . . . 
    static void Main(string[] args)
    {
       byte[] originalMsg;
       const String msg = "Sensitive message in the String";
       Encoding unicode = Encoding.Unicode;
       byte[] msgBytes = unicode.GetBytes(msg);
       X509CertificateEx signerCert = GetSignerCert();
       X509CertificateEx recipientCert = GetRecipientCert();
       /* For Sender */
       byte[] encodedSignedCms = SignMsg(msgBytes, signerCert);
       byte[] encodedEnvelopedCms = EncryptMsg(encodedSignedCms, recipientCert);
       
       /* For Receiver */
       encodedSignedCms = DecryptMsg(encodedEnvelopedCms);
       VerifyMsg(encodedSignedCms, out origMsg));
       unicode.GetString(origMsg));
    }
    static public X509CertificateEx GetSignerCert()
    {
    . . . 
    . . .
    X509Store storeMy = new X509Store(StoreName.My,
    StoreLocation.CurrentUser);
    ...
    //  Find the signer's certificate.
    X509CertificateExCollection certColl =
    storeMy.Certificates.Find(X509FindType.FindBySubjectName,
    signerName, false);
    ...
    return certColl[0];
    }
    
    static public X509CertificateEx GetRecipientCert()
    {
    //  Open the AddressBook local user X509 certificate store.
    X509Store storeAddressBook = new X509Store(StoreName.
    AddressBook, StoreLocation.CurrentUser);
    storeAddressBook.Open(OpenFlags.ReadOnly);
    ...
    //  Get recipient certificate.
    X509CertificateExCollection certColl = storeAddressBook.
    Certificates.Find(X509FindType.FindBySubjectName,
    recipientName, false);
    ... 
    return certColl[0];
    }
    static public byte[] SignMsg(Byte[] msg, X509CertificateEx signerCert)
    {
    // Place message in a ContentInfo object.
    // This is required to build a SignedCms object.
    ContentInfo contentInfo = new ContentInfo(msg);
    
    // Instantiate SignedCms object with the ContentInfo 
    // above.
    // Has default SubjectIdentifierType IssuerAndSerialNumber.
    // Has default Detached property value false, so message is 
    // included in the encoded SignedCms.
    SignedCms signedCms = new SignedCms(contentInfo);
    
    // Formulate a CmsSigner object, which has all the needed
    // characteristics of the signer.
    CmsSigner cmsSigner = new CmsSigner(signerCert);
    
    // Sign the PKCS #7 message.
    signedCms.ComputeSignature(cmsSigner);
    
    // Encode the PKCS #7 message.
    return signedCms.Encode();
    }
    
    static public bool VerifyMsg(byte[] encodedSignedCms,
    out byte[] origMsg)
    {
    
    // Prepare a SignedCms object in which to decode
    // and verify.
    SignedCms signedCms = new SignedCms();
    …
    signedCms.Decode(encodedSignedCms);
    …
    // Verify signature. 
    signedCms.CheckSignature(true);
    
    origMsg = signedCms.ContentInfo.Content;
    return true;
    }
    
    static public byte[] EncryptMsg(Byte[] msg, X509CertificateEx recipientCert)
    {
    // Place message in a ContentInfo object.
    // This is required to build an EnvelopedCms object.
    ContentInfo contentInfo = new ContentInfo(msg);
    
    // Instantiate EnvelopedCms object with the ContentInfo
    // above.
    // Has default SubjectIdentifierType IssuerAndSerialNumber.
    // Has default ContentEncryptionAlgorithm property value
    // RSA_DES_EDE3_CBC.
    EnvelopedCms envelopedCms =
    new EnvelopedCms(contentInfo);
    
    // Formulate a CmsRecipient object that
    // represents information about the recipient
    // to encrypt the message for.
    CmsRecipient recip1 = new CmsRecipient(
    SubjectIdentifierType.IssuerAndSerialNumber,
    recipientCert);
    
    // Encrypt the message for the recipient.
    envelopedCms.Encrypt(recip1);
    
    // The encoded EnvelopedCms message contains the encrypted
    // message and the information about each recipient that
    // the message was enveloped for.
    return envelopedCms.Encode();
    }
    
    // Decrypt the encoded EnvelopedCms message.
    static public Byte[] DecryptMsg(byte[] encodedEnvelopedCms)
    {
    // Prepare object in which to decode and decrypt.
    EnvelopedCms envelopedCms = new EnvelopedCms();
    
    // Decode the message.
    envelopedCms.Decode(encodedEnvelopedCms);
    
    // Decrypt the message for the single recipient.
    envelopedCms.Decrypt(envelopedCms.RecipientInfos[0]);
    return envelopedCms.Encode();
    }
    

    Références :
    Exploration des nouveautés dans le CLR 2.0
    Message CMS/PKCS #7 enveloppé et signé
    Classe X509Certificate2

  • SecureString : Cette classe stocke les données à l'aide de DPAPI (Data Protection API). Les données sont toujours dans leur forme cryptée si elles sont stockées dans une chaîne SecureString. Elles sont décryptées uniquement lors de l'accès aux données. Cela limite l'exposition aux informations sensibles. Ensuite, le .NET 2.0 Framework garantit que le Garbage Collector ne déplace pas ces chaînes sécurisées dans la mémoire. SecureString hérite également de CriticalFinalizerObject, ce qui garantit que la mémoire où la chaîne cryptée a été stockée est vidée à plusieurs reprises, puis fait l'objet d'une suppression le plus rapidement possible. [Cette classe CriticalFinalizerObject est disponible pour l'héritage par les classes personnalisées, ainsi que pour le nettoyage déterministe de la mémoire. Consultez Classe CriticalFinalizerObject.] Il est également possible de convertir une instance de chaîne sécurisée en lecture seule, afin qu'elle ne puisse pas être modifiée. Les chaînes sécurisées ne permettent pas l'inspection, la comparaison ou la conversion de ses instances. Les développeurs doivent convertir la chaîne sécurisée en chaîne binaire afin de pouvoir manipuler ou comparer la valeur d'un objet SecureString. La conversion d'un type SecureString en String s'oppose à l'objectif d'utilisation de SecureString. Une fois qu'un objet SecureString est copié vers un objet String, la valeur est présente en mémoire et tous les risques associés à l'utilisation de la classe String sont désormais applicables. Par exemple, si le mot de passe est lu à partir d'une zone de texte, la propriété .Text renvoie la valeur en tant que String et sa copie dans une classe SecureString n'offre plus de sécurité à ce stade. Cela tient au fait que les chaînes sont immuables et que par défaut, le nettoyage de la mémoire est non déterministe. Les méthodes telles que Process.Start, par exemple, ont été surchargées afin d'accepter les objets SecureString. Cependant, le code significatif reste tel que la propriété .Text d'une zone de texte qui renvoie toujours une chaîne standard.

    Listing 6

    bool Login() 
    {
    string loginName;
    SecureString password;
    bool successful = false;
    ...
    
    ReadLoginName(loginName);
    while(true) {
       ConsoleKeyInfo keypressed = Console.ReadKey(true);
       if (keypressed == ConsoleKey.Enter)
          successful = VerifyLogin(loginName, password);
       else 
          password.AppendChar(keypressed.KeyChar);
    }
    password.Clear();
    return successful;    
    }
    

    Référence :
    Classe SecureString

  • ProtectedMemory : La classe offre des méthodes pour le cryptage des données sensibles en mémoire. Cela empêche l'exposition des informations sensibles en cas de vidage de la mémoire ou si une autre application tente d'accéder aux informations sensibles dans l'espace des processus d'une application. La classe offre deux wrappers pour l'API de protection des données non gérées, à savoir Protect et Unprotect. La méthode Protect crypte les données et place le résultat dans la même mémoire. La méthode Unprotect décrypte la mémoire et fournit le résultat dans la même variable. Les données doivent être un multiple de 16 octets. Une classe similaire, à savoir ProtectedData, peut être utilisée pour protéger les données persistantes enregistrées sur le disque. Référence :
    Méthode ProtectedMemory.Protect

  • Cryptage XML : EncryptedXml est la principale classe utilisée pour le cryptage XML dans le .NET Framework. Cette classe implémente la spécification W3C (World Wide Web Consortium) pour le cryptage XML. Bien que l'entrée de l'implémentation de cette classe ne doit pas être au format XML, la sortie l'est. Elle permet également de crypter des parties d'un document XML ou de crypter différentes parties du même document avec des clés différentes. Elle peut fonctionner conjointement avec les signatures numériques XML.

    Listing 7

    void () 
    {
    ... 
    xmlDoc.Load("PersonalInfo.xml");
    ...
       
    // Create a new TripleDES key. 
    TripleDESCryptoServiceProvider tDESkey = new TripleDESCryptoServiceProvider();
    
    // Encrypt the "SSN" element.
    Encrypt(xmlDoc,tDESkey,"SSN");
    
    // Decrypt the encrypted element.
    Decrypt(xmlDoc,tDESkey);
    }
    
    public void Encrypt(XMLDocument docValue,TripleDES algValue, string Element) 
    { 
    // Find the element by name and create a new 
    // XmlElement object. 
    XmlElement inputElement = docValue.GetElementsByTagName(Element)[0] as    XmlElement; 
    
    // Create a new EncryptedXml object. 
    EncryptedXml exml = new EncryptedXml(docValue); 
    
    // Encrypt the element using the symmetric key. 
    byte[] rgbOutput = exml.EncryptData(inputElement, algValue, false); 
    
    // Create an EncryptedData object and populate it. 
    EncryptedData ed = new EncryptedData(); 
    
    // Specify the namespace URI for XML encryption 
    // elements. 
    ed.Type = EncryptedXml.XmlEncElementUrl; 
    
    // Specify the namespace URI for the TrippleDES 
    // algorithm. 
    ed.EncryptionMethod = new EncryptionMethod(EncryptedXml.XmlEncTripleDESUrl); 
    
    // Create a CipherData element. 
    ed.CipherData = new CipherData(); 
    
    // Set the CipherData element to the value of the 
    // encrypted XML element. 
    ed.CipherData.CipherValue = rgbOutput; 
    
    // Replace the plaintext XML elemnt with an 
    // EncryptedData element. 
    EncryptedXml.ReplaceElement(inputElement, ed, false); 
    }
    
    public void Decrypt(XMLDocument docValue,TripleDES algValue) 
    { 
    
    // XmlElement object. 
    XmlElement encryptedElement = docValue.GetElementsByTagName("EncryptedData")[0] as XmlElement; 
    
    // Create an EncryptedData object and populate it. 
    EncryptedData ed = new EncryptedData(); 
    ed.LoadXml(encryptedElement); 
    
    // Create a new EncryptedXml object. 
    EncryptedXml exml = new EncryptedXml(); 
    
    // Decrypt the element using the symmetric key. 
    byte[] rgbOutput = exml.DecryptData(ed, algValue); 
    
    // Replace the encryptedData element with the plaintext 
    // XML elemnt. 
    exml.ReplaceData(encryptedElement, rgbOutput); 
    }
    

    Référence :
    Classe EncryptedXml

  • Signatures XML : La classe SignedXML qui implémente la spécification W3C (World Wide Web Consortium) de la signature et de la vérification XML est la classe principale utilisée pour les signatures numériques XML dans le .NET Framework. Elle offre un moyen interopérable de signer et de vérifier tout ou partie d'un document XML ou d'autres données adressables à partir d'un URI (Uniform Resource Identifier).

    Listing 8

    void example () 
    {
    SignXmlFile("Example.xml", "signedExample.xml", Key);
    bool result = VerifyXmlFile("SignedExample.xml", Key);
    }
    
    // Sign an XML file and save the signature in a new file. This method 
    // does not save the public key within the XML file. This file cannot be 
    // verified unless the verifying code has the key with which it was 
    // signed. 
    
    public static void SignXmlFile(string FileName, string SignedFileName, RSA Key) 
    { 
    // Create a new XML document. 
    XmlDocument doc = new XmlDocument(); 
    
    // Load the passed XML file using its name. 
    doc.Load(new XmlTextReader(FileName)); 
    
    // Create a SignedXml object. 
    SignedXml signedXml = new SignedXml(doc); 
    
    // Add the key to the SignedXml document. 
    signedXml.SigningKey = Key; 
    
    // Create a reference to be signed. 
    Reference reference = new Reference(); 
    reference.Uri = "http://www.foundstone.com"; 
    
    // Add an enveloped transformation to the reference. 
    XmlDsigEnvelopedSignatureTransform env = new XmlDsigEnvelopedSignatureTransform(); 
    reference.AddTransform(env); 
    
    // Add the reference to the SignedXml object. 
    signedXml.AddReference(reference); 
    
    // Compute the signature. 
    signedXml.ComputeSignature(); 
    
    // Get the XML representation of the signature and save 
    // it to an XmlElement object. 
    XmlElement xmlDigitalSignature = signedXml.GetXml(); 
    
    // Append the element to the XML document. 
    doc.DocumentElement.AppendChild(doc.ImportNode (xmlDigitalSignature, true)); 
    
    if (doc.FirstChild is XmlDeclaration) 
    { 
    doc.RemoveChild(doc.FirstChild); 
    } 
    
    // Save the signed XML document to a file specified 
    // using the passed string. 
    XmlTextWriter xmltw = new XmlTextWriter(SignedFileName, new UTF8Encoding(false)); 
    
    doc.WriteTo(xmltw); 
    xmltw.Close(); 
    }
    
    // Verify the signature of an XML file against an asymetric 
    // algorithm and return the result. public static Boolean 
    
    VerifyXmlFile(String Name, RSA Key) 
    { 
    // Create a new XML document. 
    XmlDocument xmlDocument = new XmlDocument(); 
    
    // Load the passed XML file into the document. xmlDocument.Load(Name); 
    
    // Create a new SignedXml object and pass it 
    // the XML document class. 
    SignedXml signedXml = new SignedXml(xmlDocument); 
    
    // Find the "Signature" node and create a new 
    // XmlNodeList object. 
    XmlNodeList nodeList = xmlDocument.GetElementsByTagName("Signature"); 
    
    // Load the signature node. 
    signedXml.LoadXml((XmlElement)nodeList[0]); 
    
    // Check the signature and return the result. 
    return signedXml.CheckSignature(Key); 
    }
    

    Référence :
    Classe SignedXml

  • Application FIPS : Permet de garantir que seuls les algorithmes conformes à FIPS 140-1 sont utilisés. Dans le cas contraire, une exception est générée. Celle-ci doit être utilisée conjointement avec un paramètre de stratégie Windows XP SP2 et peut s'avérer utile dans les environnements de sécurité élevée, par exemple dans les domaines de la défense et du gouvernement.

    Référence :
    .Blog sur la sécurité .NET : Application de la cryptographie certifiée FIPS

  • Fonction de dérivation de clé basée sur mot de passe : offre une implémentation de la RFC 2898 et permet aux développeurs d'utiliser un mot de passe pour crypter un bloc de données en utilisant le mot de passe pour générer une clé symétrique.

    Listing 9

    byte[] salt = new byte[] { 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 
    0x07, 0x08, 0x09, 0x0A, 0x0B, 0x0C};
    Rfc2898DeriveBytes  pdb = new Rfc2898DeriveBytes ("*S3cr3Tk3Y*", salt);
    // Encrypt the data.
    TripleDES encAlg = TripleDES.Create();
    encAlg.Key = pdb.GetBytes(16);
    
    //Use key and encrypt
    
    pdb.Reset();
    

    Référence :
    Classe PasswordDeriveBytes

  • Clés de nom renforcé plus volumineuses : L'outil SN (sn -k) peut prendre en charge des clés d'une taille allant jusqu'à 16 384 bits. Cela permet des clés plus longues, et donc plus difficiles à découvrir via une attaque de type force brute. Cela permet également aux développeurs d'applications de se conformer aux méthodes recommandées largement acceptées, dont certaines sont étudiées dans les références ci-dessous.

    Références :
    Sélection de tailles de clés cryptographiques (1999)
    Outil nom renforcé (Sn.exe)

Code géré

Le code géré est du code écrit dans l'un des nombreux langages pris en charge par le .NET Framework. Ces langages partagent un ensemble unifié de bibliothèques de classes, et lorsqu'ils sont compilés, ils génèrent du code IL (Intermediate Language) plutôt que directement du code machine natif. Lors de l'exécution, ce code IL est compilé avec JIT (juste-à-temps) en code natif. La gestion de la mémoire, parmi d'autres fonctions essentielles, est gérée par le Common Language Runtime plutôt que par des programmes individuels, d'où la classification « géré ». L'utilisation de code géré permet aux développeurs d'éviter les vulnérabilités de sécurité courantes pouvant entraîner la compromission du système. Cependant, le code géré n'est pas non plus une panacée. Même écrit dans un langage géré, une application peut toujours être susceptible de résoudre les vulnérabilités. Le .NET Framework 2.0 fournit certaines nouvelles fonctionnalités afin de mieux équiper les développeurs, ce qui leur permet de développer des applications plus sûres Il fournit des mécanismes de défense renforcée, qui limitent les dommages même si une application est compromise. Nous allons ensuite étudier ces nouvelles fonctionnalités de sécurité.

  • Gestion des processus : Process.Start présente désormais une surcharge qui permet aux développeurs d'exécuter une application dans le contexte d'un autre utilisateur, sans avoir à gérer l'API LogonUser ou à effectuer tout autre type d'appel natif de la plate-forme. En spécifiant son nom de fichier, son nom d'utilisateur, son mot de passe et son domaine, le nouveau processus et son thread principal sont créés. Listing 10

    public static Process Start ( string fileName, string arguments, 
    string userName, SecureString password, string domain )
    
       filename : Name of the application file that is to be executed
       arguments: Command line arguments for the process to be executed
       userName: The user name to use for starting the process
       password: Password corresponding to the username specified as a securestring object
       domain: The domain to use for starting the process
    

    Référence :
    Méthode Process.Start (String, String, SecureString, String)

Extensions Kerberos de Windows Server 2003

  • Transition de protocole : L'extension de transition de protocole permet à un service qui utilise Kerberos d'obtenir un ticket de service Kerberos au nom d'une entité Kerberos vers le service, sans nécessiter que l'entité s'authentifie initialement auprès du Centre de distribution de clés (KDC, Key Distribution Center) Kerberos avec les informations d'identification. Cela signifie que le développeur peut utiliser un mécanisme d'authentification non Kerberos pour authentifier les utilisateurs de l'application, puis générer ultérieurement des jetons à l'aide du constructeur WindowsIdentity avec simplement le nom d'utilisateur, sans le mot de passe. Le processus appelant qui utilise la transition de protocole doit posséder les privilèges « Usuper l'identité » et « Agir en tant que partie du système d'exploitation » pour pouvoir usurper l'identité d'un autre utilisateur.

  • Délégation contrainte : L'extension de délégation contrainte permet à un service d'obtenir des tickets de service (sous l'identité des utilisateurs délégués) vers un sous-ensemble d'autres services après la présentation d'un ticket de service obtenu via le protocole TGS_REQ, tel que défini dans IETF RFC 1510, ou avec l'extension de transition de protocole étudiée ci-dessus. Pour qu'un compte de service utilise la transition de protocole avec délégation contrainte, un nouvel indicateur de contrôle appelé T2A4D (Trusted-to-Authenticate-for-Delegation) doit être défini. Cet indicateur est défini sur le compte de service dans Active Directory.

    Référence :
    Transition de protocole Kerberos et délégation contrainte

  • Authentification : Les applications peuvent utiliser les nouvelles classes NegotiateStream et SslStream pour l'authentification et pour permettre la sécurité des informations échangées entre un client et un serveur. Ces classes de flux authentifiées prennent en charge l'authentification mutuelle, le cryptage de données et la signature de données. La classe NegotiateStream utilise le protocole de sécurité Negotiate pour l'authentification et fournit un wrapper géré pour la fonctionnalité SSPI, qui tente d'utiliser d'abord Kerberos, puis revient à NTLM. Une fois l'authentification terminée, un canal sécurisé est établi, afin de garantir que toutes les données communiquées font l'objet d'une protection d'intégrité à l'aide d'un code d'authentification de message et d'un cryptage. La classe SslStream utilise les certificats X.509 pour l'authentification. Elle permet au client de rechercher les éventuelles révocations de certificat serveur et de fournir un certificat client pour l'authentification mutuelle. Une fois l'authentification terminée, une clé de session partagée est établie et toutes les communications ultérieures font l'objet d'une protection de l'intégrité et d'un cryptage.

    Références :
    Classe SslStream
    Classe NegotiateStream
    Améliorations de la sécurité dans le .NET Framework 2.0

  • Canaux d'accès distant sécurisés : Le canal IPC est nouveau dans l'accès distant. Les avantages de ce canal tiennent au fait qu'il utilise des canaux nommés pour la communication, lesquels peuvent ainsi facilement faire l'objet de listes de contrôle d'accès (ACL). En outre, ce canal est accessible uniquement à partir de l'ordinateur local. Par conséquent, il peut uniquement être utilisé si le serveur d'accès distant et le client résident sur le même ordinateur physique. Le canal TCP prend désormais également en charge l'authentification et le cryptage via SSPI. Il est également possible d'identifier l'appelant et d'exécuter avec les autorisations associées à l'identité de l'appelant.

    <configuration> 
       <system.runtime.remoting> 
          <application> 
             <channels> 
                <channel ref="tcp" 
                      impersonationLevel="Identify" 
                      authenticationPolicy="Policy, policy" />
    

    Référence : Authentification avec le canal TCP

  • Listes de contrôle d'accès gérées : L'espace de nom System.Security.AccessControl permet l'accès à tous les objets de contrôle d'accès Windows natifs, tels que les SACL, DACL, ACE et SID. L'API ACL gérée facilite l'utilisation des ACL en fournissant plusieurs méthodes pouvant être utilisées pour obtenir et définir des ACL pour chaque ressource. Une utilisation potentielle d'une ACL gérée serait le développement d'autorisations propres à l'application sur des fichiers journaux, pouvant être configurées de manière dynamique par l'administrateur de l'application, sans avoir à gérer la boîte de dialogue d'autorisation de fichier Windows native, mais dans le contexte des utilisateurs et rôles propres à l'application.

    Listing 12

    void Main() 
    {
    ...
    ...
    string filename = "logfile.txt";
    /* Add Permission */
    ProvideAccessToFile(filename, @"DomainName\AccountName", 
    FileSystemRights.AppendData, AccessControlType.Allow);
    
    
       /* Remove Permission */
       RemoveAccessToFile(filename, @"DomainName\AccountName", 
       FileSystemRights.AppenData, AccessControlType.Allow);
    ...
    ...
    }
    
    void ProvideAccessToFile(string fileName, string accountInfo, 
    FileSystemRights permissions, AccessControlType accessControl) 
    {
       // Get a FileSecurity object that represents the current security settings. 
       FileSecurity fSecurity = File.GetAccessControl(fileName); 
       // Add the FileSystemAccessRule to the security settings. 
       fSecurity.AddAccessRule(new FileSystemAccessRule(accountInfo, 
       permissions, accessControl)); 
       // Set the new access settings. 
       File.SetAccessControl(fileName, fSecurity);
    }
    
    void RemoveAccessToFile(string fileName, string accountInfo, FileSystemRights permissions, 
    AccessControlType accessControl) 
    {
    // Get a FileSecurity object that represents the // current security 
    settings. FileSecurity fSecurity = File.GetAccessControl(fileName); 
    
    // Add the FileSystemAccessRule to the security settings. 
    fSecurity.RemoveAccessRule(new FileSystemAccessRule(accountInfo, 
    permissions, accessControl)); 
    
    // Set the new access settings. 
    File.SetAccessControl(fileName, fSecurity);
    }
    

    Référence :
    Propriété MiningModel.Properties

  • Contexte d'exécution : Cette nouvelle classe permet au programmeur de contrôler l'exécution des threads. Elle offre toutes les informations pertinentes relatives à l'exécution d'un thread. Elle inclut également le contexte de sécurité, le contexte d'appel, le contexte de synchronisation, le contexte de localisation et le contexte de transaction. Le développeur peut capturer ces informations de contexte et éventuellement les transférer du thread actuel vers un autre thread.

    Listing 13

    static void Callme(object obj) 
    {
     // The security context does not from the previous threat
    // The threads executes under the privileges of the process owner
    Console.WriteLine("The process is executing under the permissions of 
    {0}", WindowsIdentity.GetCurrent().Name);
    }
    
    Static void Main () 
    {
    IntPtr accessToken = IntPtr.Zero;
    If (LogonUser("UserName","Foundstone", "Password", LOGON32_LOGON_NETWORK, 
    LOGON32_PROVIDER_DEFAULT, accessToken)) 
    {
       WindowsImpersonationContext wic = WindowsIdentity.Impersonate(accessToken);
       executionContext.SupperFlow();
       ThreatPool.QueueUserWorkItem(Callme);
       wic.Undo();
    }
    ...
    ...
    }
    

    Référence :
    Espace de nom System.Security.AccessControl

  • API Active Directory : L'espace de nom System.DirectoryServices.ActiveDirectory permet un accès facile aux API de type ADSI (Active Directory Service Interfaces) dans le monde géré, ce qui permet aux développeurs d'effectuer les tâches de gestion Active Directory. Les concepts Active Directory tels que les forêts, les domaines, les sites, les partitions de sous-réseau et les schémas font partie de ce modèle d'objet.

    Référence :
    Espace de nom System.DirectoryServices.ActiveDirectory

Prise en charge des outils

Enfin, le .NET Framework et Visual Studio 2005 offrent aux développeurs et aux testeurs un certain nombre d'autres outils et utilitaires pour faciliter le débogage et le test des applications de manière plus efficace et complète. Certains appliquent des stratégies, tandis que d'autres effectuent des vérifications statiques et d'exécution. Visual Studio 2005 offre également une version Team puissante, permettant aux développeurs et testeurs de collaborer et d'améliorer ainsi leur productivité. Nous allons étudier brièvement quelques-uns des principaux nouveaux outils :

  • FxCop : FxCop est un outil d'analyse de code qui vérifie les assemblys de code géré .NET pour la conformité aux instructions de conception du Microsoft .NET Framework. Il est conçu pour détecter plus de 200 défaillances, notamment l'injection SQL, les problèmes d'autorisation et les problèmes de nom renforcé. Pour la liste complète des règles de sécurité, reportez-vous aux références ci-dessous.

    Références :
    FxCop sur GotDotNet
    Vue d'ensemble de Visual Studio Team System : Analyse du code géré pour la recherche des défaillances du code

  • PREfast : Cet outil effectue l'analyse du code source statique afin de détecter certaines catégories d'erreurs et de bogues. Dans la plupart des cas, un compilateur n'intercepte pas ces erreurs. L'outil fonctionne sur les applications créées en C/C++ et peut effectuer des vérifications des vulnérabilités de sécurité, telles que les débordements de mémoire tampon, la mémoire non initialisée et les pertes de mémoire.

    Référence :
    PREfast

  • Standard Annotation Language : SAL permet la définition des hypothèses faites par une fonction sur ses paramètres, ainsi que des effets secondaires ultérieurs. Le compilateur peut utiliser ces informations pour générer automatiquement des routines de validation de clés afin d'appliquer ces déclarations.

    Référence :
    Annotations SAL

  • Vérificateur d'applications : Ensemble de vérifications standard pouvant être utilisées au cours du processus de test des applications. Il se concentre sur la détection des problèmes courants concernant la sécurité et la qualité des applications, par exemple la corruption de tas, l'utilisation de pointeurs invalides, l'utilisation de verrous, les chemins de fichiers et les vérifications de registre. Il est destiné uniquement à une utilisation avec le code non géré.

    Référence :
    Vérificateur d'applications Windows

  • Couverture du code et test sous contraintes : Visual Studio Team Edition offre plusieurs fonctionnalités permettant aux développeurs et aux testeurs de créer des produits de meilleure qualité. Parmi ces fonctionnalités, citons la possibilité de gérer les tests, d'évaluer la couverture du code, de procéder à des tests Web et d'exécuter des tests sous contraintes et des tests de charge. Ces fonctionnalités permettent d'identifier les points actifs qui sont exécutés fréquemment, ainsi que le code mort et les morceaux de code faisant rarement l'objet d'accès, et qui risquent donc de ne pas être testés correctement. Par exemple, l'outil de test Web permet à l'équipe de développement d'enregistrer des sessions Web entières dans le navigateur, puis de les relire ou d'extraire les informations précieuses pouvant conduire à une compromission du système.

    Référence :
    Centre développeur Visual Studio Team System : testeurs logiciels

Conclusion

Dans ce document, nous avons tenté d'étudier certains des changements majeurs de Microsoft .NET Framework 2.0 et de Visual Studio 2005. L'objectif était de collecter ces informations et de les présenter sous forme d'une seule source, claire et concise. Bien que nous n'ayons pas répertorié chaque fonctionnalité de sécurité, nous avons tenté de fournir des détails et liens suffisants vers davantage d'informations sur cet aspect, ainsi que sur d'autres aspects, de cette version. Les lecteurs sont invités à suivre ces liens pour découvrir plus en détail chacune des fonctionnalités décrites ci-dessus, ainsi que pour obtenir davantage d'informations sur les fonctionnalités non étudiées ici.

En conclusion, il est important de noter que toutes les fonctionnalités disponibles dans le .NET Framework, ainsi que les outils correspondants, ne dispensent pas les développeurs de se concentrer sur la sécurité de leurs applications. Ces fonctionnalités sont simplement destinées à permettre aux équipes de développement de faire les bons choix, du point de vue de la sécurité.

Annexe de références

Retrouvez toutes les annexes à jour sur la version anglais de l’article : http://msdn.microsoft.com/netframework/default.aspx?pull=/library/en-us/dnnetsec/html/foundstone.asp#founds_topic11

À propos des auteurs

Rudolph Araujo

Rudolph Araujo est consultant en sécurité logicielle et formateur chez Foundstone. Chez Foundstone, Rudolph est responsable de la création et la fourniture de la modélisation des menaces et des lignes de service de vérification du code de sécurité. Rudolph est également responsable de la création de contenu et de la formation pour Foundstone Building Secure Software and Writing Secure Code : classe ASP.NET.

Rudolph possède d'excellentes bases informatiques et une expérience de nombreuses années dans le développement de logiciels, dans les environnements UNIX et Windows. Avant de rejoindre Foundstone, Rudolph a dirigé l'équipe de développement des vérifications pour BindView bv-Control for Internet Security, un produit d'évaluation des vulnérabilités. Il a également travaillé en tant que développeur de logiciels chez Morgan Stanley. Plus récemment, Rudolph a travaillé comme chercheur pour le laboratoire CYLAB de l'université Carnegie Mellon University, dans le domaine des virus et des vers, en particulier dans les réseaux d'égal à égal. Ses intérêts en termes de recherche couvrent également le domaine de la sécurité et de la fiabilité des services Web.

Rudolph possède un Masters Degree de l'université Carnegie Mellon University, avec une spécialisation sur la sécurité informatique, et un Bachelors Degree en ingénierie informatique, de l'université de Goa en Inde. Il est un développeur C / C++ et C#/.NET expérimenté, auteur des outils Foundstone .NET Security Toolkit, SSLDigger et Hacme Bank. Rudolph est également présentateur des séries Webcast de MSDN. Rudolph a reçu la récompense Microsoft Visual Developer : Security MVP, pour son travail et sa contribution dans les communautés sur la sécurité et le développement d'applications. Rudolph participe également à plusieurs journaux en ligne et papier, tels que Software Magazine, où il écrit un article sur l'écriture de code sécurisé.

Shanit Gupta

Shanit Gupta est consultant et formateur en sécurité chez Foundstone. Shanit est spécialisé dans l'évaluation des vulnérabilités, les tests de pénétration, l'évaluation des applications Web et les initiatives de développement sécurisé de logiciels.

Shanit dispose d'excellentes connaissances en informatique et d'une expérience de nombreuses années dans le développement de logiciels. Avant de rejoindre Foundstone, Shanit a été impliqué dans le développement de systèmes d'exploitation en temps réel et dans le prototype de service d'authentification Kerberos de Carnegie Mellon. Shanit a également travaillé chez Alcoa Inc., en tant que développeur en charge de la création d'applications internes critiques.

Shanit possède un Masters de l'université Carnegie Mellon University, avec une spécialisation sur la sécurité informatique, et un Bachelors en informatique, de l'université Osmania. Il est un développeur C / C++ et C#/.NET expérimenté et le responsable de projet des outils Foundstone gratuits tels que Validator.NET, .NETMon et CookieDigger.

Remerciements

Nous remercions Shawn Farkas et Mike Downen qui, grâce à leurs blogs respectifs, ont pris sur eux de former les développeurs .NET sur les nouvelles fonctionnalités de sécurité du .NET Common Language Runtime. Nombre des éléments de ce document ont également été compilés sur la base des discussions des MVP Microsoft Developer Security. Nous remercions également Ron Nguyen, Robert Deane et Nicholas Murison de Foundstone pour leur contribution à la rédaction technique. Enfin, merci à Rick Samona, Mike Downen et Mike Howard de Microsoft pour la révision technique de ce document.

À propos de Foundstone Professional Services

Foundstone Professional Services, une division de McAfee, offre une combinaison unique de services et de formation afin d'aider les entreprises à protéger en permanence et de façon mesurable les ressources les plus importantes, contre les menaces les plus critiques. Grâce à une approche stratégique de la sécurité, Foundstone identifie, recommande et implémente le juste équilibre entre technologie, personnes et processus, afin de gérer le risque numérique et d'exploiter plus efficacement les investissements en termes de sécurité.

Les services S3i (Secure Software Security Initiative) de Foundstone aident les organisations à concevoir et à développer des logiciels sécurisés. En intégrant la sécurité dans le cycle de développement des logiciels, les organisations peuvent réduire de manière significative le risque d'attaque malveillante et donc les coûteux efforts de réparation. Les services sont les suivants :

  • Audits du code source

  • Examen de la conception et de l'architecture des logiciels

  • Modélisation des menaces

  • Test de pénétration des applications Web

  • Statistiques et mesures de sécurité des logiciels

Consultez le site Web de Foundstone Web pour plus d'informations sur les services S3i de Foundstone.

Afficher:
© 2015 Microsoft