Exporter (0) Imprimer
Développer tout

Questions de sécurité que se posent les programmeurs en Visual Basic .NET et Visual C# .NET

Visual Studio .NET 2003

Robin Reynolds-Haertle
L'équipe Visual Studio
Microsoft Corporation

Résumé : cet article s'intéresse aux questions de sécurité que doivent résoudre les programmeurs en Visual Basic .NET et Visual C# .NET lorsqu'ils commencent à utiliser le .NET Framework. Cette présentation aborde les applications Windows et Web, ainsi que les phases d'implémentation, de débogage et de déploiement du développement.

Elle concerne les versions finales de Visual Studio .NET et de .NET Framework. Si vous utilisez des versions préliminaires, il se peut que vos applications ne fonctionnent pas exactement comme indiqué dans ce document.

Sommaire

Introduction
Sécurité d'accès au code
   Confiance totale
   Confiance partielle
   Développement d'application pour un environnement de confiance partielle
   Test
   Autres ressources
Applications Web
   Découverte dynamique
   Authentification, emprunt d'identité et délégation
   Identité du processus ASPNET
   Sécurisation des ressources de fichiers en cas de fonctionnement sous l'identité ASPNET
   Débogage avec l'identité ASPNET
Mécanismes de sécurité dans l'environnement de développement Visual Studio .NET
Conclusion

Introduction

Microsoft® Visual Studio® .NET permet de mieux contrôler la sécurité des applications en cours d'exécution que les versions précédentes. Parallèlement, il exige de votre part une programmation plus scrupuleuse. Certaines questions de sécurité sont à prendre en considération lors de la création d'applications conviviales pour les utilisateurs.

Il existe trois situations courantes qui exigeront de vous une attention particulière aux questions de sécurité :

  • Votre application peut se voir refuser des privilèges par l'utilisateur si celui-ci l'exécute depuis un emplacement défini comme n'ayant pas accès à certaines ressources du système. Par exemple, l'utilisateur peut configurer le Common Language Runtime de telle sorte que les applications stockées sur un lecteur du réseau ne bénéficient d'aucun accès aux fichiers. Pensez-y lorsque vous écrivez votre code et veillez à gérer correctement les refus d'accès.
  • Les utilisateurs qui accèdent à vos applications Web à partir de vos serveurs Web ne doivent pas pouvoir exécuter des programmes malveillants ni endommager vos données.
  • La manière dont vous configurez Visual Studio peut placer votre serveur dans une situation plus ou moins risquée face à ces attaques.

Sécurité d'accès au code

La sécurité d'accès au code est le système de .NET Framework qui contrôle l'accès aux ressources en surveillant l'exécution du code. Cette fonction de sécurité est distincte et complémentaire de la sécurité intrinsèque du système d'exploitation. Lorsque votre application est exécutée par un utilisateur, le .NET Common Language Runtime lui affecte une zone. Les cinq zones possibles sont les suivantes :

  • Poste de travail : applications de l'ordinateur de l'utilisateur.
  • Intranet Local : applications de l'intranet de l'utilisateur.
  • Internet : applications sur Internet.
  • Sites de confiance : applications provenant de sites définis comme "Sites de confiance" dans Internet Explorer.
  • Sites sensibles : applications provenant de sites définis comme "Sites sensibles" dans Internet Explorer.

À chacune des zones correspondent des autorisations d'accès spécifiques définies par un administrateur système. Le niveau de sécurité d'une zone peut être défini à : confiance totale, confiance moyenne, confiance faible ou confiance nulle. Les niveaux de confiance définissent les ressources auxquelles une application a accès. La zone, ainsi que d'autres preuves de sécurité telles que l'éditeur, le nom fort, le site Web et l'URL du code, déterminent les autorisées accordées au code au moment de l'exécution. Vous n'avez aucun contrôle sur les paramètres de sécurité de l'ordinateur de l'utilisateur, et cependant votre application doit fonctionner avec les paramètres qu'elle rencontre. Cela signifie que l'accès à certaines ressources lui sera refusé. Par exemple, votre application peut être amenée à écrire des données dans un fichier alors que le système de l'utilisateur interdit tout accès en écriture au moment de l'exécution en déclenchant une exception. Pour plus d'informations sur les preuves de sécurité, reportez-vous à l'article Evidence leave-msdn france Site en anglais.

Votre tâche consiste à développer une application capable de gérer ce type de situation. Cela ne signifie pas nécessairement que votre application doit rechercher une autre manière d'écrire les données. Simplement, elle doit pouvoir anticiper une éventuelle incapacité d'écrire les données et réagir en conséquence. Ainsi, pour renforcer votre code, vous pouvez faire plus largement appel à la gestion des exceptions (Try…Catch dans Visual Basic ou try…catch dans C#) ou à des objets de l'espace de noms System.Security.Permissions. Ces méthodes sont rapidement décrites plus loin dans cet article, sous le titre "Développement pour les environnements de confiance partielle".

Les niveaux de sécurité des zones se définissent à l'aide des outils d'administration qui s'installent avec .NET Framework. Pour en savoir plus sur le paramétrage des niveaux de sécurité pour les zones d'un ordinateur, reportez-vous à l'article Administration Tools leave-msdn france Site en anglais.

Confiance totale

Les développeurs travaillent souvent dans un environnement de confiance totale. Ils conservent leur code source sur leurs disques durs et testent leurs applications sur leurs ordinateurs de développement. Dans cet environnement de confiance totale, tout code compilé par le développeur peut être exécuté sur l'ordinateur local. Aucune exception n'est alors générée puisque l'ordinateur local est défini par défaut comme un environnement de confiance totale.

Confiance partielle

Pour toute zone qui n'est pas une zone de confiance totale, on parle de confiance partielle. Lorsqu'une application est déployée, elle peut passer dans une zone nouvelle, qui n'accorde pas nécessairement la confiance totale à l'application. Les deux situations les plus courantes d'exécution de code en confiance partielle sont les suivantes :

  • Exécution d'un code téléchargé à partir d'Internet
  • Exécution d'un code résidant sur un partage réseau (intranet)

Les ressources auxquelles l'accès peut être refusé dans une zone de confiance partielle sont par exemple :

  • E/S de fichier, notamment lecture, écriture, création, suppression ou impression de fichiers
  • Composants système, tels que les valeurs de registre et variables d'environnement
  • Composants serveur, tels que les services d'annuaire, le registre, les journaux d'événements, les compteurs de performances et les files d'attente de messages

Que n'autorise pas la confiance partielle ? Voilà qui n'est pas simple à déterminer. Chaque classe et chaque méthode de chaque classe de .NET Framework a un attribut de sécurité qui définit le niveau de confiance nécessaire pour exécuter cette méthode, et il se peut que cet attribut ne soit pas disponible lors de l'exécution en raison précisément des fonctions de sécurité. Le niveau de sécurité de la zone n'est pas un simple mappage du niveau de confiance sur les attributs, mais un ensemble de permissions spécifiques attribuées à des classes et à des méthodes particulières. Votre application ne pourra pas se contenter d'interroger le niveau de confiance puis d'en déduire les ressources disponibles et indisponibles. Simplement, vous pouvez savoir si vos applications fonctionnent ou non en confiance totale. Une méthode à cet effet est présentée dans la section suivante.

Développement d'application pour un environnement de confiance partielle

Cette section propose un rapide aperçu de l'éventuel impact des questions de sécurité sur le code que vous écrivez. Il n'existe pas de solution unique pour développer des applications qui fonctionneront en environnement de confiance partielle. La solution dépend de l'application développée. De plus, le niveau de confiance étant susceptible de changer pendant l'exécution de l'application, il ne suffit pas de tester le niveau de confiance existant.

La première étape dans le développement d'applications destinées à des zones de confiance partielle consiste à écrire un code apte à reconnaître l'apparition d'exceptions de sécurité. Supposons le code suivant :

' Visual Basic
Public Sub MakeABitmap()
 Dim b As Bitmap = New Bitmap(100, 100)
 ' Code ici pour dessiner une belle image dans le bitmap
 b.Save("c:\PrettyPicture.bmp")
End Sub

// C#
public void MakeABitmap()
{
 Bitmap b = new Bitmap(100, 100);
 // Code ici pour dessiner une belle image dans le bitmap
 b.Save("c:\\PrettyPicture.bmp");
}

Cette méthode fonctionne sans lever d'exception si le projet et l'assembly du projet sont stockés sur le disque dur de votre ordinateur et si vous êtes membre du groupe des administrateurs de votre ordinateur. Si vous déployez cette application sur votre intranet, une exception System.Security.SecurityException (voir l'article SecurityException Class leave-msdn france Site en anglais) est levée lorsque l'application tente d'enregistrer l'objet bitmap. S'il n'existe pas de bloc Try…Catch (Visual Basic) ou try…catch (C#) autour de ce code, votre application prend fin avec l'exception. Pour l'utilisateur, ce n'est pas très satisfaisant. En revanche, si vous ajoutez un code de gestion des exceptions, votre application peut :

  • Avertir l'utilisateur qu'elle ne peut accomplir toutes les tâches demandées
  • Nettoyer tous les objets existants afin que le code qui suit le bloc catch ne provoque pas d'erreur

Vous pouvez modifier le code d'enregistrement de bitmap de la façon suivante. Le code ajouté avertit l'utilisateur que le fichier n'a pas été enregistré suite à un refus d'accès par la sécurité, et il sépare les incidents de sécurité des autres échecs d'E/S de fichiers, tels que ceux dus à des noms de fichiers incorrects. Cette méthode ne crée aucune brèche dans le système de sécurité. L'utilisateur devra modifier la sécurité pour accorder la confiance à votre application ; à défaut, celle-ci ne fonctionnera pas.

' Visual Basic
Public Sub MakeABitmap()
 Dim b As Bitmap
 Try
 b = New Bitmap(100, 100)
 b.Save("c:\PrettyPicture.bmp")
 Catch ex As System.Security.SecurityException
 ' L'utilisateur est averti que l'enregistrement a échoué. 
 MessageBox.Show("L'autorisation d'enregistrer le fichier a été refusée " & _
 "et le bitmap n'a pas été enregistré.")
 Catch ex As System.Exception
 ' Réagissez aux autres exceptions ici.
 MessageBox.Show(ex.Message)
 End Try
End Sub

// C#
public void MakeABitmap()
{
 Bitmap b = null;
 try 
 {
 b = new Bitmap(100, 100);
 b.Save("c:\\PrettyPicture.bmp");
 } 
 catch (System.Security.SecurityException ex) 
 {
 // L'utilisateur est averti que l'enregistrement a échoué. 
 MessageBox.Show("L'autorisation d'enregistrer le fichier a été refusée " + 
 "et le bitmap n'a pas été enregistré.");
 } 
 catch (System.Exception ex) 
 {
 // Réagissez aux autres exceptions ici.
 MessageBox.Show(ex.Message);
 }
}

Les classes, les attributs et les énumérations de l'espace de noms System.Security.Permissions offrent un plus grand contrôle sur les tâches de sécurité de votre application. Si vous écrivez des bibliothèques appelées par d'autres applications, elles devront vérifier les autorisations du code appelant. Par exemple, vous pouvez ajouter l'attribut de niveau assembly au début de votre code. Au moment du chargement de l'assembly, le runtime vérifie l'autorisation. En cas de refus, l'assembly ne se charge pas et une exception de sécurité est levée. Toutefois, si vous ajoutez cet attribut dans une application autonome, celle-ci risque de ne pas fonctionner. De même, si vous l'ajoutez dans une bibliothèque de classes, celle-ci risque de ne pas se charger au moment de l'exécution. Il convient dans ce cas d'ajouter un bloc try/catch au code qui appelle la bibliothèque de classes.

' Visual Basic
<Assembly: System.Security.Permissions.FileIOPermissionAttribute( _
SecurityAction.RequestMinimum, Write:="c:\PrettyPicture.bmp")>
 
// C#
[assembly: System.Security.Permissions.FileIOPermissionAttribute(
SecurityAction.RequestMinimum, Write="c:\\PrettyPicture.bmp")]

Une autre solution consiste à demander spécifiquement des autorisations au runtime, à l'aide de la méthode Demand, comme ci-après. Le runtime peut alors accorder ou refuser l'autorisation. En cas de refus, une exception de sécurité est levée. Vous pouvez récrire le code de la façon suivante pour demander explicitement l'autorisation d'écriture dans le fichier bitmap :

' Visual Basic
Public Sub MakeABitmap()

Dim filename As String = "c:\PrettyPicture.bmp"

Dim permission As FileIOPermission = _


New FileIOPermission(FileIOPermissionAccess.Write, _


filename)

 Dim b As Bitmap = Nothing
 Try
 b = New Bitmap(100, 100)

permission.Demand()

 b.Save(filename)
 Catch ex As System.Security.SecurityException
 ' L'utilisateur est averti que l'enregistrement a échoué. 
 MessageBox.Show("L'autorisation d'enregistrer le fichier a été refusée " & _
 "et le bitmap n'a pas été enregistré.")
 Catch ex As System.Exception
 ' Réagissez aux autres exceptions ici.
 MessageBox.Show(ex.Message)
 End Try
End Sub

// C#
using System.Security.Permissions;
public void MakeABitmap()
{

string filename = "c:\\PrettyPicture.bmp";


FileIOPermission permission = new


FileIOPermission(FileIOPermissionAccess.Write,


filename);

 Bitmap b = null;
 try 
 {
 b = new Bitmap(100, 100);

permission.Demand();

 b.Save(filename);
 } 
 catch (System.Security.SecurityException ex) 
 {
 // L'utilisateur est averti que l'enregistrement a échoué. 
 MessageBox.Show("L'autorisation d'enregistrer le fichier a été refusée " + 
 "et le bitmap n'a pas été enregistré.");
 } 
 catch (System.Exception ex) 
 {
 // Réagissez aux autres exceptions ici.
 MessageBox.Show(ex.Message);
 }
}

Test

La seconde étape du développement d'applications pour des zones de confiance partielle consiste à effectuer des tests dans plusieurs environnements, en particulier depuis votre intranet et depuis Internet. Ceci force la levée des exceptions de sécurité.

Autres ressources

Naturellement, les options possibles sont bien plus nombreuses que celles décrites précédemment. Les articles suivants traitent plus en détail de la sécurité d'accès au code :

Applications Web

La sécurité des applications Web protège vos serveurs des codes malveillants et de la corruption des données. Il existe plusieurs moyens de protéger votre serveur.

  • Vous pouvez empêcher les utilisateurs de rechercher et d'exécuter vos Services Web en désactivant la découverte dynamique de ces derniers.
  • L'authentification permet de vérifier l'identité d'un utilisateur avant de lui accorder l'accès à votre serveur.
  • Avec l'identité de processus ASPNET, vous pouvez définir précisément les ressources mises à disposition d'un utilisateur.

Chacune de ces méthodes est explicitée plus loin dans cet article.

Découverte dynamique

La découverte dynamique est une fonction de .NET Framework qui permet aux navigateurs Web de rechercher les Services Web exécutés sur un serveur. Lorsqu'il trouve un service Web XML, l'utilisateur peut en appeler les méthodes. La découverte dynamique est donc une fonction très puissance pour l'utilisateur, mais elle génère aussi un risque pour la sécurité de votre serveur. Le plus souvent, vous choisirez de ne pas activer la découverte dynamique et, par défaut, elle est désactivée au moment de l'installation de .NET Framework. Cela ne signifie pas que les Services Web ne sont pas disponibles ; simplement, le serveur ne propose pas un annuaire des services disponibles. Pour que les clients continuent d'utiliser les Services Web, vous devrez leur en indiquer l'emplacement exact.

Attention   Lorsque la découverte dynamique est désactivée, vous devez communiquer à vos clients l'emplacement de vos Services Web.

Deux éléments contrôlent la détectabilité d'un service Web XML sur le serveur de déploiement. Le premier élément, le fichier machine.config, contrôle la capacité globale de découverte du serveur. Il s'agit d'un fichier XML, situé dans le dossier \%windows%\Microsoft.NET\Framework\Version\Config, qui contient les paramètres contrôlant les applications Web sur le serveur. Ce fichier contient un élément mis en commentaire par défaut. Pour activer la découverte, supprimez les caractères de commentaire. Vous devez en outre exécuter votre application en utilisant le compte ASPNET, comme indiqué plus bas dans la section "Identité du processus ASPNET".

<!--<add verb="*" path="*.vsdisco" 
type="System.Web.Services.Discovery.DiscoveryRequestHandler, 
System.Web.Services, Version=1.0.3300.0, Culture=neutral, 
PublicKeyToken=b03f5f7f11d50a3a" validate="false"/>-->

Le second élément est un fichier de découverte. Celui-ci peut être le fichier par défaut, default.vsdisco, ou un fichier spécifique du service Web XML. Le fichier de découverte, de type XML, contient des informations sur l'emplacement des fichiers du service Web XML.

Pour qu'un service Web XML soit découvert, vous devez activer la découverte dans le fichier machine.config puis créer et déployer un fichier de découverte pour l'application. Le fichier XML de découverte fournit simplement la liste des chemins d'accès dans lesquels ne figurent pas les Services Web. Vous en trouverez un exemple ci-dessous. Pour savoir comment créer et déployer ce fichier, reportez-vous à l'article Deploying Web Services in Managed Code leave-msdn france Site en anglais.

<?xml version="1.0" encoding="utf-8" ?>
<dynamicDiscovery xmlns="urn:schemas-dynamicdiscovery:disco.2000-03-17">
 <exclude path="_vti_cnf" />
 <exclude path="_vti_pvt" />
 <exclude path="_vti_log" />
 <exclude path="_vti_script" />
 <exclude path="_vti_txt" />
 <exclude path="Références Web" />
</dynamicDiscovery>

Si Visual Studio .NET est installé sur votre serveur de déploiement, le dossier racine du Web contient le fichier de découverte par défaut, default.vsdisco, créé pendant l'installation de Visual Studio .NET. Si le serveur contient ce fichier et si la découverte est activée dans le fichier machine.config, tous les Services Web de votre serveur peuvent être découverts. Pour en empêcher la découverte, supprimez ce fichier.

Attention   Si Visual Studio .NET est installé sur votre serveur de déploiement, supprimez le fichier default.vsdisco avant de mettre le serveur en production.
Il est recommandé de ne pas déployer de services Web XML sur des serveurs sur lesquels Visual Studio .NET est également installé. L'installation de Visual Studio .NET ajoute des fichiers et des utilisateurs à votre système à des fins d'exploitation. Vous pouvez sécuriser un système sur lequel Visual Studio .NET est installé, mais si vous n'en avez pas besoin sur le serveur de déploiement, il est préférable de ne pas l'y installer.

Pour plus d'informations sur l'activation de la découverte dynamique, reportez-vous aux articles Enabling Discovery for an XML Web Service leave-msdn france Site en anglais et http://msdn.microsoft.com/library/en-us/vbcon/html/vbconFineTuningDiscoveryMechanisms.asp Fine-Tuning Discovery Mechanisms leave-msdn france Site en anglais.

Authentification, emprunt d'identité et délégation

Par défaut, les applications Web fonctionnent en mode anonyme, c'est-à-dire qu'elles ne disposent d'aucune information concernant l'identité de l'utilisateur. Ceci ne pose pas de problème avec les sites contenant des informations publiques. Si vous souhaitez contrôler les accès à votre application ou à d'autres ressources, ajoutez l'authentification à votre application. L'authentification est le processus qui consiste à identifier l'utilisateur de votre application et à vérifier qu'il a l'autorisation d'accès correspondante. Il existe plusieurs méthodes d'authentification prises en charge par ASP.NET. Les méthodes les plus couramment utilisées sont les suivantes :

  • Anonyme   Aucune information d'identité n'est demandée à l'utilisateur. Cette méthode convient aux sites Web dont le contenu est public. Si la personnalisation du site est nécessaire, il est possible d'utiliser des cookies. Pour plus d'informations sur l'utilisation de cookies dans les applications ASP.NET, reportez-vous à l'article Introduction to Web Forms State Management leave-msdn france Site en anglais.
  • Formulaires   L'application présente à l'utilisateur un formulaire qui nécessite la saisie dinformations de connexion, telles que le nom et le mot de passe. Le formulaire est renvoyé au serveur qui compare les informations fournies avec celles stockées dans un magasin de données.
  • De base   L'authentification de base peut être configurée à l'aide des services IIS (Internet Iinformation Services) et est prise en charge par la plupart des navigateurs. Lorsqu'elle est activée, le navigateur demande à l'utilisateur son nom et son mot de passe, puis renvoie ces informations à l'application ASP.NET en utilisant le codage Base64, facilement déchiffrable. Avec cette méthode, les utilisateurs doivent posséder des comptes Windows. L'utilisation du protocole Secure Sockets Layer (SSL) en plus de l'authentification de base sécurise en outre cette méthode d'authentification. Pour plus d'informations concernant la prise en charge de SSL dans ASP.NET, reportez-vous à l'article Using Secure Sockets Layer leave-msdn france Site en anglais.
  • Digest   L'authentification Digest peut être configurée à l'aide d'IIS. Elle est disponible sur les serveurs utilisant Microsoft Windows® 2000 ou Windows XP. L'authentification Digest offre un niveau de cryptage de mot de passe renforcé comparativement à celui de l'authentification de base. Avec cette méthode, les utilisateurs doivent posséder des comptes Windows stockés dans Microsoft Active Directory®.
  • Authentification intégrée de Windows   L'authentification intégrée de Windows est similaire aux authentifications de base et Digest, si ce n'est que le nom et le mot de passe de l'utilisateur ne sont pas renvoyés à l'application Web. Cette méthode est particulièrement bien adaptée aux environnements intranet. Elle nécessite que les utilisateurs disposent d'un compte Windows et n'est prise en charge que par le navigateur Internet Explorer.
  • Certificat   Un certificat est une clé numérique installée sur un ordinateur. Lorsque l'utilisateur tente d'accéder à votre serveur, la clé est présentée. Le serveur authentifie ensuite le certificat dans un domaine ou un répertoire actif. Cette méthode est adaptée aux applications dont l'exigence de sécurité est prioritaire par rapport au coût de gestion des certificats.
  • Passport   Microsoft offre ce service centralisé d'authentification. L'authentification Passport est idéale lorsque votre site Web est utilisé avec d'autres sites Passport, ce qui permet une connexion unique pour tous les sites, ou si vous ne souhaitez pas gérer une base de données d'utilisateurs.

Grâce à l'authentification, vous autorisez l'utilisateur à accéder à votre application, sans toutefois lui donner accès aux ressources telles que les fichiers et les bases de données. Vous pouvez configurer vos ressources pour qu'elles soient accessibles à certains utilisateurs et non à l'application elle-même. Dans ce cas, utilisez l'emprunt d'identité afin de donner aux utilisateurs l'accès aux ressources. Lorsque vous utilisez l'emprunt d'identité, le processus serveur s'exécute avec l'identité de l'utilisateur authentifié. Lorsque votre application utilise l'emprunt d'identité et interroge une base de données, l'application de base de données traite la demande comme si elle émanait de l'utilisateur et non du serveur. Pour activer l'emprunt d'identité, il convient de définir l'attribut impersonate de l'élément d'identité du fichier Web.config de l'application, comme indiqué ci-après. Un fichier Web.config est créé dans chaque projet d'application Web.

<identity impersonate="true">

Le niveau au-dessus de l'emprunt d'identité est la délégation, qui utilise l'identité de l'utilisateur avec un accès aux ressources distantes (d'autres ordinateurs). Toutes les méthodes d'authentification ne prennent pas en charge la délégation, comme le montre le tableau suivant.

Prend en charge la délégation Ne prend pas en charge la délégation
De base Anonyme
Intégrée de Windows Digest
Certificat Passport
  Formulaires

Pour plus d'informations sur le choix et l'implémentation d'une méthode d'authentification, reportez-vous à l'article Authentication in ASP.NET: .NET Security Guidance leave-msdn france Site en anglais. Pour plus d'informations sur la sécurité des applications Web, reportez-vous à l'article Web Application Security at Run Time leave-msdn france Site en anglais.

Identité du processus ASPNET

Lorsque votre application Web démarre sur un serveur, elle ne s'exécute pas comme si c'était vous, l'auteur de cette application Web, qui l'ouvriez, mais en utilisant un des comptes d'utilisateur Windows définis sur le serveur. Ce compte, également appelé identité, est un des trois comptes suivants: identité ASPNET, identité SYSTEM ou identité personnalisée. L'identité est spécifiée dans le fichier XML machine.config, situé dans le dossier \%windows%\Microsoft.NET\Framework\Version\Config du serveur. Vous trouverez ci-dessous un exemple simplifié de ces trois configurations. L'élément du fichier a plusieurs attributs qui n'apparaissent pas dans cet exemple.

<!-- Sélectionnez l'identité ASPNET -->
<system.web>
 <processModel enable="true" username="MACHINE" password="AutoGenerate"/>
</system.web>

<!-- Sélectionnez l'identité SYSTEM -->
<system.web>
 <processModel enable="true" username="SYSTEM" password="AutoGenerate"/>
</system.web>

<!-- Sélectionnez une identité personnalisée -->
<system.web>
 <processModel enable="true" username="domain\user" password="pwd"/>
</system.web>

ASPNET est l'identité sélectionnée par défaut lorsque le fichier machine.config est installé avec le .NET Framework. Le compte ASPNET appartient au groupe des utilisateurs, lequel ne dispose par défaut que de privilèges réduits. Le compte ASPNET possède de son côté quelques autres privilèges, en particulier des privilèges complets sur les répertoires ASP.NET et temporaire Windows.

Si vous changez au profit de l'identité SYSTEM, votre application s'exécute avec l'identité System et bénéficie des privilèges du groupe des administrateurs. Le compte System a accès à presque toutes les ressources du serveur.

Attention   L'exécution sous l'identité SYSTEM expose votre serveur au risque le plus élevé d'attaque de code malveillant et de corruption de données.

Pour utiliser une identité personnalisée, vous devez créer le compte et configurer ses privilèges de façon spécifique. Pour plus d'informations sur la création d'une identité personnalisée, reportez-vous à l'article Authentication in ASP.NET: .NET Security Guidelines leave-msdn france Site en anglais.

Par défaut, certaines ressources système ne sont pas accessibles au compte ASPNET. Les restrictions et solutions courantes sont indiquées ci-dessous. Il est recommandé d'utiliser le compte ASPNET et les solutions présentées, au lieu d'exécuter l'application avec l'identité System.

  • Ressources de fichiers   Vous pouvez adapter les privilèges de fichiers et de dossiers accordés au compte ASPNET en accédant aux listes de contrôle d'accès (ACL) des fichiers et des dossiers par le biais de l'Explorateur Windows. Les modifications apportées aux ACL du compte ASPNET ne se propagent pas automatiquement lors du déploiement. Supposons par exemple que le compte ASPNET possède des autorisations en écriture sur le fichier c:\picture.bmp de votre ordinateur de développement. Lorsque vous allez déployer l'application, elle s'exécutera sur un ordinateur différent ayant également un compte ASPNET. Vous devrez alors ajouter pour le compte ASPNET des autorisations en écriture sur le fichier c:\picture.bmp de cet ordinateur de déploiement. Heureusement, vous pouvez modifier les ACL par l'intermédiaire d'actions personnalisées dans le projet de déploiement, sans omettre toutefois de garder la trace des changements à effectuer.
  • Journaux d'événements   Le compte ASPNET ne peut créer de nouvelles catégories de journaux d'événements, bien qu'il puisse ajouter des entrées dans un journal existant. Pour permettre la création de nouvelles catégories de journaux d'événements, utilisez l'emprunt d'identité avec le compte ASPNET. L'emprunt d'identité doit disposer des privilèges suffisants pour créer ces catégories. Si vous devez spécifier des journaux d'événements pour l'application avant la production, créez-le par le biais du projet de déploiement.
  • Services d'annuaire et répertoire actif   L'accès à ces services nécessite l'emprunt d'identité et la délégation ou, à défaut, la transmission aux objets DirectoryEntry d'informations d'authentification de sécurité. Si vous choisissez cette seconde solution, vous devez vérifier que ces informations sont stockées correctement.
  • Compteurs de performances   Le compte ASPNET peut écrire des données dans les compteurs de performances, mais il ne peut pas les lire ni créer de nouvelles catégories de compteurs de performances. Pour permettre la création de nouvelles catégories de compteurs de performances, utilisez l'emprunt d'identité avec le compte ASPNET. L'emprunt d'identité doit disposer de privilèges suffisants pour créer ces catégories. Si vous devez spécifiez des compteurs de performances pour l'application avant production, créez-les par le biais du projet de déploiement.

Sécurisation des ressources de fichiers en cas de fonctionnement sous l'identité ASPNET

Remarque   Les instructions décrites dans cette section s'appliquent aux systèmes exécutant le système de fichiers NTFS. Si votre serveur exécute le système de fichiers FAT32, consultez sa documentation pour savoir comment sécuriser les fichiers.

Par défaut, le compte ASPNET ne dispose que des privilèges de lecture et d'exécution du groupe des utilisateurs. Si votre application Web doit écrire dans des fichiers ou en créer de nouveaux, vous pouvez accorder des permissions à certains fichiers et dossiers en modifiant les listes de contrôle d'accès (ACL). Pour accéder aux ACL d'un fichier, cliquez avec le bouton droit sur le fichier à partir de l'Explorateur Windows, sélectionnez Propriétés, puis l'onglet Sécurité. Il est préférable de modifier les ACL de certains fichiers, plutôt que d'ajouter des privilèges généraux au compte ASPNET. Les permissions qui vous concernent le plus sont les suivantes :

  • Lecture : les fichiers de données et les fichiers exécutables ont besoin d'autorisations en lecture.
  • Écriture : les fichiers de données qui sont mis à jour par l'application nécessitent l'accès en écriture.
  • Exécution : dans les applications Web, les fichiers .asmx sont des fichiers exécutables.
  • Création : pour créer des fichiers, vous devez accorder des autorisations de création pour le dossier dans lequel le fichier doit être créé.

Ces privilèges s'appliquent aux :

  • Fichiers
  • Dossiers
    Attention   La combinaison à éviter est d'autoriser l'écriture ou la création en même temps que l'exécution dans le même fichier ou répertoire. Dans ce cas en effet, un utilisateur pourrait écrire du code malveillant dans le fichier et l'exécuter.

Voici quelques conseils qui simplifient le processus des autorisations :

  • Répartissez les fichiers de votre application dans des répertoires selon les autorisations qu'il requièrent. Par exemple, si vous ne placez que des fichiers en lecture/exécution dans un répertoire, il vous suffit ensuite de définir les autorisations sur le répertoire et non sur chaque fichier. Vous avez la possibilité de définir des répertoires séparés dans l'application pour les autorisations en lecture/exécution, lecture/écriture, lecture/création.
  • Votre application peut contenir un fichier de données vide au moment déploiement, et contenir parallèlement un code qui créera le fichier à la première exécution. Dans ce cas, il est nécessaire de définir des autorisations de création pour un répertoire, ce qui est un niveau de sécurité élevé. Aussi, au lieu d'ajouter un code à appliquer au fichier vide pour le créer, distribuez un fichier vide avec l'application au moment déploiement. De cette manière, il suffira de définir des autorisations en écriture sur le fichier au lieu d'autorisations de création pour le répertoire.

À mesure que vous développerez votre application, vous serez amené à ajouter des autorisations sur les fichiers et répertoires de l'ordinateur de développement, afin d'affiner le niveau de sécurité. Malheureusement, les ACL ne seront pas transférées vers les fichiers correspondants sur l'ordinateur de déploiement. Pour planifier le transfert de ces ACL, tenez compte des éléments suivants :

  • Vous pouvez utiliser des actions personnalisées dans le package de déploiement pour modifier les ACL. Pour plus d'informations, reportez-vous à l'article Custom Actions leave-msdn france Site en anglais.
  • Il existe des outils mis au point par d'autres fournisseurs pour assurer le suivi et la recherche des modifications effectuées.
  • Vous aurez probablement à justifier chaque configuration auprès de l'administrateur système. Vous devrez aussi expliquer la nécessité du changement envisagé et expliquer pourquoi il n'est pas réalisable sans modification des données existantes.

Débogage avec l'identité ASPNET

Lorsque vous déboguez un service Web XML, il sera appelé avec l'identité ASPNET, si l'identité a été définie de cette manière dans le fichier machine.config. L'identité ASPNET n'appartient pas au groupe des utilisateurs du débogueur par défaut (reportez-vous à la section suivante, "Mécanismes de sécurité dans l'environnement de développement Visual Studio .NET"), de sorte que vous n'aurez pas accès au code du service Web XML lors du débogage. Pour déboguer un service Web XML, ouvrez son code et définissez un point d'arrêt.

Il est recommandé d'effectuer le débogage sur un ordinateur de test plutôt que sur un ordinateur de déploiement. Pour plus d'informations, reportez-vous à la section suivante, "Mécanismes de sécurité dans l'environnement de développement Visual Studio .NET".

Pour en savoir plus sur la configuration de l'identité du processus, reportez-vous aux articles ASP.NET Process Identity leave-msdn france Site en anglais et http://msdn.microsoft.com/library/en-us/cpguide/html/cpconaspnetimpersonation.asp ASP.NET Impersonation leave-msdn france Site en anglais.

Mécanismes de sécurité dans l'environnement de développement Visual Studio .NET

Il est important de protéger non seulement vos serveurs, mais aussi vos ordinateurs de développement contre les attaques de codes malveillants et la corruption des données. L'environnement de développement offre plusieurs mécanismes pour vous aider à sécuriser les serveurs de développement :

Développeurs et débogueurs VS   Ces deux groupes de compte s'installent avec Visual Studio .NET. Le groupe des développeurs VS dispose des permissions de type fichier, partage et IIS nécessaires à la création et au développement d'applications Web sur un serveur. Le groupe des débogueurs a la possibilité de déboguer les processus d'un ordinateur, qu'il soit local ou distant. Ces deux groupes sont des utilisateurs puissants du serveur car ils ont accès à la plupart des ressources. Pour plus d'informations, reportez-vous à l'article Web Application Security at Design Time in Visual Studio leave-msdn france Site en anglais.

Débogage    Il est recommandé d'effectuer le débogage sur un ordinateur de test plutôt que sur un ordinateur de déploiement. Si toutefois vous devez déboguer sur un serveur de déploiement, installez uniquement le composant de débogage distant et désinstallez-le lorsque vous avez terminé. Pendant le débogage, placez le serveur hors connexion. Pour plus d'informations, reportez-vous à l'article Introduction to Web Application Debugging leave-msdn france Site en anglais.

Déploiement   Pour la plupart des applications et si le .NET Framework seul est installé sur le serveur, ce niveau est suffisant. Si Visual Studio .NET ou les composants serveur de Visual Studio .NET sont installés sur l'ordinateur de déploiement, les groupes de développeurs VS et de débogueurs figureront tous sur le serveur de déploiement. Vous devrez donc limiter les membres des utilisateurs développeurs VS et débogueurs. De plus, vous avez la possibilité de désactiver la découverte dynamique.

Attention   Il est vivement recommandé de ne pas installer Visual Studio sur votre serveur de déploiement.

Le fonction de copie d'un projet de Visual Studio .NET permet de déployer une application avec un fichier de configuration (Web.config) différent de celui utilisé pour le développement. Si la fonction de débogage du fichier de développement est activée, comme c'est probable, les utilisateurs peuvent, en cas de déploiement, examiner la pile des appels lorsqu'une exception est levée. Par conséquent, il est conseillé d'effectuer le déploiement avec un fichier de configuration distinct qui ne permet pas le débogage.

Conclusion

La sécurisation des ressources est un processus qui met en oeuvre plusieurs technologies et couvre l'ensemble du cycle de développement. Vous pouvez créer des applications hautement sécurisées en accordant un soin particulier aux phases de conception, d'implémentation, de test et de déploiement. Les technologies de sécurité proposées par ASP.NET, le système d'exploitation et les navigateurs Web offrent différentes solutions pour sécuriser vos applications.



Dernière mise à jour le mercredi 29 mai 2002



Pour en savoir plus
Afficher:
© 2014 Microsoft