Exporter (0) Imprimer
Développer tout

Sécurisation de votre application ASP.NET et de vos services Web

Dernière mise à jour le 31 août 2004
Sur cette page

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Méthodologie Méthodologie
À savoir avant de commencer À savoir avant de commencer
Description de Machine.Config et de Web.Config Description de Machine.Config et de Web.Config
Instructions d'utilisation de Machine.Config et de Web.Config Instructions d'utilisation de Machine.Config et de Web.Config
Niveaux de confiance dans ASP.NET Niveaux de confiance dans ASP.NET
Identité de processus ASP.NET Identité de processus ASP.NET
Emprunt d'identité Emprunt d'identité
Authentification Authentification
Autorisation Autorisation
État de session État de session
État d'affichage État d'affichage
Clé ordinateur Clé ordinateur
Débogage Débogage
Traçage Traçage
Gestion des exceptions Gestion des exceptions
Accès distant Accès distant
Services Web Services Web
Ressources protégées Ressources protégées
Répertoire Bin Répertoire Bin
Journal d'événements Journal d'événements
Accès aux fichiers Accès aux fichiers
Listes de contrôle d'accès et autorisations Listes de contrôle d'accès et autorisations
Registre Registre
Accès aux données Accès aux données
Partages UNC Partages UNC
Ressources COM/DCOM Ressources COM/DCOM
Considérations relatives au déni de service Considérations relatives au déni de service
Considérations relatives aux batteries de serveurs Considérations relatives aux batteries de serveurs
Instantané d'une application ASP.NET sécurisée Instantané d'une application ASP.NET sécurisée
Résumé Résumé
Ressources supplémentaires Ressources supplémentaires

Dans ce module

Pour être protégées, les applications Web ASP.NET doivent reposer sur une infrastructure de plate-forme, un environnement hôte et un réseau parfaitement sécurisés. Dans ce cas de figure, les pirates tenteront alors d'exploiter les vulnérabilités des applications et des services Web, qui écoutent généralement sur le port 80. Si l'application Web n'est pas configurée correctement, les pirates pourront s'infiltrer dans le système.

En tant qu'administrateur, vous avez la responsabilité d'examiner la configuration par défaut des ordinateurs et les configurations propres à chaque application en vue d'éliminer toute vulnérabilité et de corriger toute erreur de configuration.

Ce module décrit les nouveautés d'ASP.NET du point de vue des administrateurs système et explique comment configurer les paramètres de sécurité à l'échelle de l'ordinateur et ceux qui sont propres à chaque application. Il présente également une méthodologie visant à protéger les applications et les services Web ASP.NET, en complément de la méthodologie proposée pour protéger le réseau, le serveur d'applications, le serveur de base de données et le serveur Web.

Objectifs

Ce module vous permettra d'effectuer les opérations suivantes :

  • stocker les informations d'authentification et les chaînes de connexion dans le Registre à l'aide de l'utilitaire Aspnet_setreg.exe ;

  • utiliser les fichiers de configuration (*.config) pour gérer l'environnement d'application Web ;

  • découvrir la hiérarchie selon laquelle Machine.config et Web.config sont appliqués et traités ;

  • verrouiller les paramètres de configuration ;

  • appliquer les stratégies de sécurité à l'échelle des ordinateurs et des applications Web ;

  • personnaliser les paramètres de sécurité des fichiers et des répertoires à l'aide de l'élément <location> ;

  • protéger l'identité du processus ASP.NET et utiliser l'emprunt d'identité d'un compte prédéfini dans les applications ASP.NET ;

  • connaître les autorisations NTFS requises pour les comptes de processus ASP.NET ;

  • protéger les ressources via l'authentification par formulaire et l'autorisation d'accès à l'URL ;

  • sécuriser l'état de session ASP.NET ;

  • sécuriser une batterie de serveurs et protéger le répertoire bin.

S'applique à

Ce module s'applique aux produits et technologies suivants :

  • Microsoft Windows Server 2000 ;

  • Microsoft .NET Framework 1.1 et ASP.NET 1.1 ;

  • Microsoft SQL Server 2000.

Méthodologie

Pour sécuriser votre application ASP.NET, commencez par vérifier que votre environnement de système d'exploitation et votre installation .NET Framework sont renforcés. Appliquez ensuite à votre application des paramètres de configuration sécurisés afin de limiter sa vulnérabilité face aux attaques.

Ces paramètres concernent les éléments suivants :

  • Les services. Le .NET Framework installe le service d'état ASP.NET pour gérer les états de session hors processus ASP.NET. Si vous installez le service d'état ASP.NET, sécurisez-le. Si vous n'avez pas besoin du service d'état ASP.NET, désactivez-le.

  • Les protocoles. Limitez les protocoles de service Web afin de réduire la surface d'attaque.

  • Les comptes. Le compte ASPNET créé par défaut sert à exécuter les applications Web, les services Web et le service d'état ASP.NET. Si vous créez d'autres comptes pour exécuter les processus ou les services, réduisez au maximum leurs privilèges en leur accordant uniquement les autorisations NTFS et les privilèges Windows qui sont strictement nécessaires.

  • Les fichiers et les répertoires. Les répertoires Bin des applications, qui stockent les assemblys privés, doivent être protégés afin de réduire le risque qu'un pirate télécharge la logique métier.

  • Le magasin de configuration. De nombreux paramètres de sécurité à caractère fonctionnel, tels que l'authentification, l'autorisation et l'état de session, sont stockés dans les fichiers de configuration XML Machine.config et Web.config. Pour sécuriser les applications ASP.NET, vous devez utiliser des paramètres de configuration sécurisés.

À savoir avant de commencer

Avant d'entreprendre la sécurisation de vos applications et de vos services Web, vous devez connaître les caractéristiques essentielles de l'infrastructure ASP.NET.

Modèle de processus ASP.NET

Dans Microsoft Windows 2000, Internet Information Services (IIS) 5.0 exécute toutes les applications Web et tous les services Web dans le processus de traitement ASP.NET (Aspnet_wp.exe). L'unité d'isolation est le domaine d'application et chaque répertoire virtuel possède son propre domaine d'application. Les paramètres de configuration de niveau processus sont définis dans l'élément <processModel> de Machine.config.

Dans Microsoft Windows Server 2003, les pools d'applications IIS 6.0 permettent d'isoler les applications à l'aide de processus distincts. Pour plus d'informations, reportez-vous au module 20, « Hébergement de plusieurs applications ASP.NET ».

Compte ASP.NET

Le compte ASPNET est un compte local doté de privilèges minimum, créé lors de l'installation du .NET Framework. Par défaut, il exécute le processus de traitement ASP.NET et le service d'état ASP.NET.

Si vous décidez de lancer les applications Web à partir d'un compte configuré, veillez à lui attribuer les privilèges minimum. Vous limiterez ainsi les dommages que pourrait causer un pirate réussissant à exécuter du code dans le contexte de sécurité de l'application. Vous devez également définir les informations d'authentification du compte dans l'élément <processModel>. Veillez à ne pas stocker les informations d'authentification en clair. Utilisez plutôt l'outil Aspnet_setreg.exe pour stocker les informations d'authentification sous forme cryptée dans le Registre. Le compte configuré doit également recevoir les autorisations NTFS adéquates.

Processus, session et identité dans Aspnet_setreg.exe

Aspnet_setreg.exe vous permet de stocker les informations d'authentification et les chaînes de connexion sous forme cryptée dans le Registre. Cet outil permet de crypter les attributs suivants :

  • <processModel userName = password= />

  • <processModel userName = password= />

  • <sessionState sqlConnectionString = stateConnectionString= />

L'exemple suivant présente l'élément <processModel> définissant un compte configuré, avant et après le recours à Aspnet_setreg.exe pour sécuriser les informations d'authentification :

<!--Avant-->
<processModel userName="CustomAccount" password="Str0ngPassword" />
<!--Après-->
<processModel
 userName="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,userName"
 userName="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,userName"

Vous pouvez choisir l'emplacement des données cryptées dans le Registre, à condition que cela soit sous la clé HKEY_LOCAL_MACHINE. En plus de crypter les données à l'aide de l'API de protection des données (DPAPI) et de les stocker dans le Registre, l'outil applique une liste de contrôle d'accès (ACL, Access Control List) sécurisée pour restreindre l'accès à la clé de Registre. La liste de contrôle d'accès définie sur la clé de Registre accorde le contrôle total aux comptes Système, Administrateurs et Créateur propriétaire. Si vous utilisez l'outil pour crypter les informations d'authentification de l'élément <identity> ou la chaîne de connexion de l'élément <sessionState>, vous devez également accorder l'accès en lecture au compte de processus ASP.NET.

Pour télécharger l'outil Aspnet_setreg.exe et obtenir plus d'informations, reportez-vous à l'article 329290 de la Base de connaissances Microsoft, « Comment faire : Utilisation de l'utilitaire ASP.NET pour crypter les informations d'authentification et les chaînes de connexion de l'état de session ».

L'emprunt d'identité n'est pas activé par défaut

Par défaut, les applications ASP.NET n'effectuent pas d'emprunt d'identité. Par conséquent, c'est l'identité de processus de traitement ASP.NET qui est utilisée pour accéder aux ressources. Vous devez donc au moins accorder à l'identité de processus un accès en lecture aux ressources Windows dont l'application a besoin, en configurant une liste de contrôle d'accès.

Si vous activez l'emprunt d'identité, vous pouvez soit emprunter l'identité de l'appelant initial ? en l'occurrence, l'identité IIS authentifiée ? soit une identité prédéfinie dans l'élément <identity>. Pour plus d'informations, reportez-vous à la section « Emprunt d'identité » plus loin dans ce module.

En général, les applications ASP.NET n'utilisent pas l'emprunt d'identité car cela peut avoir une incidence négative sur la conception, la mise en œuvre et l'évolutivité. L'emprunt d'identité, par exemple, ne permet pas d'effectuer un regroupement efficace des connexions de couche intermédiaire, ce qui limite l'évolutivité de l'application. Certaines circonstances justifient le recours à l'emprunt d'identité, par exemple lorsque l'application utilise le contexte de sécurité du compte utilisateur anonyme pour accéder aux ressources. C'est une technique courante, souvent utilisée lorsque plusieurs applications sont hébergées sur le même serveur. Pour plus d'informations, reportez-vous au module 20, « Hébergement de plusieurs applications Web ».

HttpForbiddenHandler, Urlscan et 404.dll

Il existe plusieurs techniques permettant d'empêcher l'accès aux ressources protégées. ASP.NET fournit le HttpForbiddenHandler auquel vous pouvez associer les types de fichiers qui ne doivent pas pouvoir être téléchargés via HTTP. Les associations sont appliquées à l'aide de l'élément <httpHandlers>.

IISLockdown.exe fournit la 404.dll. Grâce à cet outil, vous pouvez configurer IIS de sorte qu'il mappe les extensions de fichiers indésirables sur la 404.dll, laquelle affiche le message « HTTP 404 – File not found » chaque fois que le type de fichier est demandé.

Enfin, le filtre ISAPI URLScan permet de bloquer les requêtes ciblant les types de fichiers protégés et les programmes exécutables. URLScan est fourni avec l'outil IISLockdown, mais vous pouvez également l'obtenir séparément. Reportez-vous à l'article 307608 de la Base de connaissances Microsoft, « INFO : Disponibilité de l'outil de sécurité URLScan » et « Procédure : utilisation d'URLScan » dans la section des procédures de ce guide.

Pour plus d'informations sur IISLockdown et URLScan, reportez-vous au module 16, « Sécurisation de votre serveur Web ».

AppSettings

L'élément <appSettings> du fichier Web.config permet de stocker des données de configuration propres aux applications, telles que des chaînes de connexion ou des informations d'authentification de compte de service. Cet élément présente l'avantage de permettre aux développeurs de centraliser et d'harmoniser le stockage et l'extraction des données de configuration. Le stockage centralisé dans Web.config simplifie également l'administration et le déploiement.

Les données sensibles comme les chaînes de connexion et les informations d'authentification ne doivent pas être stockées en clair dans les fichiers de configuration. Le développeur doit utiliser DPAPI pour crypter les secrets avant de les stocker.

Pour plus d'informations sur AppSettings, regardez l'émission (en anglais) « AppSettings in ASP.NET » sur MSDN® TV à l'adresse http://msdn.microsoft.com/msdntv.

Description de Machine.Config et de Web.Config

.NET Framework offre aux développeurs un large éventail de paramètres de configuration permettant de gérer l'application Web et son environnement. Ces paramètres sont stockés dans des fichiers de configuration XML. Certains d'entre eux définissent les paramètres à l'échelle de l'ordinateur et d'autres contiennent des paramètres de configuration propre à chaque application.

Les fichiers de configuration XML peuvent être ouverts et modifiés dans n'importe quel éditeur de texte, tel que Bloc-notes, ou à l'aide d'éditeurs XML. Les balises XML sont sensibles à la casse : veillez à respecter les majuscules et les minuscules.

La figure 19.1 présente les fichiers de configuration que les administrateurs peuvent utiliser pour configurer les applications Web ASP.NET.

Fichiers de configuration ASP.NET

Figure 19.1
Fichiers de configuration ASP.NET

Les fichiers Machine.config et Web.config ont de nombreuses sections de configuration et éléments XML en commun. Machine.config permet d'appliquer la stratégie d'ordinateur à toutes les applications .NET Framework exécutées sur l'ordinateur local. Les développeurs peuvent également utiliser des fichiers Web.config spécifiques aux applications pour personnaliser les paramètres de chaque application.

Remarque : les exécutables Windows, tels que les applications WinForm, sont configurés au moyen de fichiers de configuration. Le nom de ces fichiers est construit à partir du nom de l'exécutable de l'application, par exemple App.exe.config, app étant le nom de l'application.

Les modifications apportées aux fichiers de configuration sont appliquées dynamiquement et ne nécessitent pas, normalement, le redémarrage du serveur ou d'un quelconque service, à moins que la modification porte sur l'élément <processModel> de Machine.config, décrit plus loin dans ce module.

Le tableau 19.1 indique l'emplacement des fichiers de configuration.

Tableau 19.1 : Emplacement des fichiers de configuration

Fichier de configuration

Emplacement

Machine.config
(un par ordinateur, par version installée
du .NET Framework)

%windir%\Microsoft.NET\Framework\{version}\CONFIG

Web.config
(zéro, un ou plusieurs par application)

\inetpub\wwwroot\web.config
\inetpub\wwwroot\YourApplication\web.config
\inetpub\wwwroot\YourApplication\SubDir\web.config

Enterprisesec.config
(configuration de la sécurité d'accès au code à l'échelle de l'entreprise)

%windir%\Microsoft.NET\Framework\{version}\CONFIG

Security.config
(configuration de la sécurité d'accès au code à l'échelle de l'ordinateur)

%windir%\Microsoft.NET\Framework\{version}\CONFIG

Security.config
(configuration de la sécurité d'accès au code à l'échelle de l'utilisateur)

\Documents and Settings\{user}\Application
Data\Microsoft\CLR Security Config\{version}

Web_hightrust.config
Web_mediumtrust.config
Web_lowtrust.config
Web_minimaltrust.config
(configuration de la sécurité d'accès au code de l'application Web ASP.NET)

%windir%\Microsoft.NET\Framework\{version}\CONFIG

Pour plus d'informations sur les fichiers de configuration de la stratégie de sécurité d'accès au code des applications Web ASP.NET, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ».

Hiérarchie d'évaluation des stratégies

Pour centraliser l'administration, les paramètres peuvent être appliqués dans Machine.config. Les paramètres de Machine.config définissent la stratégie à l'échelle de l'ordinateur et peuvent servir à appliquer une configuration spécifique aux applications à l'aide d'éléments <location>. Les développeurs peuvent fournir des fichiers de configuration d'application pour remplacer certains paramètres de la stratégie d'ordinateur. Dans le cas des applications Web ASP.NET, le fichier Web.config se trouve dans le répertoire racine virtuel de l'application et éventuellement dans des sous-répertoires situés sous la racine virtuelle. Examinez l'organisation de la figure 19.2.

Configuration hiérarchique

Figure 19.2
Configuration hiérarchique

À la figure 19.2, l'application Web AppRoot contient un fichier Web.config dans son répertoire racine virtuel. SubDir1 (qui n'est pas un répertoire virtuel) contient également son propre fichier Web.config, qui est appliqué à chaque fois qu'une requête HTTP est dirigée vers http://AppRoot/SubDir1. Si une requête est dirigée vers SubDir2 (un répertoire virtuel) via AppRoot (par exemple : http://Server/AppRoot/SubDir2), les paramètres du fichier Machine.config et du fichier Web.config situé dans le répertoire AppRoot sont appliqués. En revanche, si une requête est dirigée vers SubDir2 sans passer par AppRoot (par exemple : http://Server/SubDir2), seuls les paramètres du fichier Machine.config sont appliqués.

Dans les deux cas, les paramètres de base proviennent de Machine.config. Ces paramètres sont ensuite modifiés et complétés par d'éventuels fichiers Web.config.

Si un même élément de configuration figure à la fois dans Machine.config et dans un ou plusieurs fichiers Web.config, le paramètre du fichier situé le plus bas dans la hiérarchie l'emporte sur les autres. Les fichiers Web.config permettent également d'appliquer de nouveaux paramètres de configuration, non prévus à l'échelle de l'ordinateur. Il est également possible d'effacer les paramètres définis au niveau parent à l'aide de l'élément <clear>.

Le tableau ci-dessous indique quels paramètres de configuration de la figure 19.2 sont retenus en cas de combinaison de requêtes Web.

Tableau 19.2 : Paramètres de configuration appliqués

Requête HTTP

Paramètres combinés suite aux requêtes

http://Server/AppRoot

Machine.config
Web.config (rép. virtuel AppRoot)

http://Server/AppRoot/SubDir1

Machine.config
Web.config (rép. virtuel AppRoot)
Web.config (SubDir1)

http://Server/AppRoot/SubDir2

Machine.config
Web.config (rép. virtuel AppRoot)

http://Server/Subdir2

Machine.config

<location>

L'élément <location> permet de réaliser trois principales tâches :

  • appliquer des paramètres de configuration à des fichiers d'application spécifique ;

  • centraliser l'administration en appliquant les paramètres spécifiques aux applications dans Machine.config ;

  • verrouiller les paramètres de configuration afin d'éviter qu'ils ne soient remplacés par d'autres paramètres au niveau des applications.

La balise <location> peut être utilisée dans Machine.config ou dans Web.config. Dans Machine.config, si vous indiquez le chemin, vous devez indiquer le chemin complet et inclure le nom du site Web, le nom du répertoire virtuel et éventuellement, le nom d'un sous-répertoire et d'un fichier. Exemple :

<location path="Web Site Name/VDirName/SubDirName/PageName.aspx" >
  <system.web> 
   . . .	
  </system.web>
</location>

Remarque : vous devez inclure le nom du site Web si vous utilisez la balise location dans Machine.config.

Dans Web.config, le chemin est relatif au répertoire virtuel de l'application. Exemple :

<location path="SubDirName/PageName.aspx" >
   <system.web> 
   . . .	
   </system.web>
</location>
Application de paramètres de configuration à des fichiers spécifiques

Utilisez l'attribut path pour appliquer des paramètres de configuration à un fichier spécifique. Par exemple, pour appliquer des règles d'autorisation au fichier Pagename.aspx à partir de Web.config, utilisez l'élément <location> suivant :

<location path="SubDirName/PageName.aspx" >
  <system.web> 
    <authorization>
      <deny roles="hackers" />
    </authorization>
    </system.web>
</location>
Application de paramètres de configuration spécifiques aux applications dans Machine.config

Il est également possible d'appliquer des paramètres de configuration spécifiques aux applications dans Machine.config, en spécifiant les chemins des répertoires des applications dans l'élément <location>. Cela présente l'avantage de centraliser l'administration. L'exemple suivant indique comment forcer l'authentification Windows et empêcher le recours à l'emprunt d'identité dans une application donnée.

<location path="Default Web Site/YourApp">
  <system.web> 
    <authentication mode="Windows"/>
    <identity impersonate="false"/>
  </system.web>
</location>
Verrouillage des paramètres de configuration

Pour éviter que les applications ignorent ou modifient la configuration de la stratégie définie à l'échelle de l'ordinateur, placez les paramètres dans un élément <location> dans Machine.config et déclarez l'attribut allowOverride="false".

Par exemple, pour appliquer une stratégie d'ordinateur qui ne puisse pas être modifiée au niveau des applications, utilisez l'élément <location> suivant :

<location path="" allowOverride="false">
  <system.web> 
    ... machine-wide defaults
  </system.web>
</location>

En laissant l'attribut path vide, vous indiquez que les paramètres s'appliquent à l'ordinateur. L'attribut allowOverride="false" garantit que les paramètres Web.config ne remplaceront pas les valeurs spécifiées. Toute tentative d'ajout d'éléments dans Web.config générera une exception, même si les éléments définis dans Machine.config correspondent à ceux définis dans Web.config.

Instructions d'utilisation de Machine.Config et de Web.Config

Machine.config contient les paramètres par défaut applicables au niveau du serveur. Si vous souhaitez appliquer une configuration spécifique pour toutes les applications du serveur, déclarez l'attribut allowOverride="false" dans l'élément <location> comme indiqué plus haut. Cela s'avère particulièrement utile dans les scénarios d'hébergement, lorsque certains aspects de la stratégie de sécurité doivent être appliqués à toutes les applications du serveur.

Lorsque les paramètres peuvent être configurés en fonction de l'application, il est normal que celle-ci fournisse un fichier Web.config. Bien qu'il soit possible de configurer chaque application à partir de Machine.config en utilisant plusieurs éléments <location>, recourir à des fichiers Web.config distincts offre des avantages en termes de déploiement et permet de limiter la taille des fichiers Machine.config.

L'enjeu principal consiste à déterminer quels paramètres doivent être appliqués par la stratégie d'ordinateur. Tout dépend des spécificités de votre scénario. Les scénarios les plus courants sont décrits ci-dessous :

  • Authentification Windows. Imaginez le cas d'un portail d'intranet d'entreprise. Vous souhaitez que l'authentification soit séparée de l'application et contrôlée à l'échelle de l'entreprise par le biais d'Active Directory. Dans ce scénario, vous pouvez appliquer l'authentification Windows tout en permettant à chaque application d'utiliser l'emprunt d'identité en appliquant la configuration suivante :

    <location path="" allowOverride="false">
      <system.web> 
        <authentication mode="Windows"/>
      </system.web>
    </location>
    
  • Scénario d'hébergement. Les sociétés d'hébergement doivent restreindre le champ d'action des applications pour éviter que celles-ci accèdent à leurs ressources respectives et pour limiter leur accès aux ressources système critiques. Pour ce faire, vous pouvez configurer toutes les applications de sorte qu'elles fonctionnent à un niveau de confiance partielle. Le niveau de confiance partielle peut par exemple limiter une application en l'autorisant uniquement à accéder aux fichiers situés dans l'arborescence de son propre répertoire virtuel et en restreignant l'accès aux autres types de ressources. Pour plus d'informations, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ». Pour appliquer une stratégie de confiance moyenne à toutes les applications de votre serveur, utilisez la configuration suivante :

    <location path="" allowOverride="false">
      <system.web> 
        <trust level="Medium" />
      </system.web>
    </location>

Listes de contrôle d'accès et autorisations

Les fichiers de configuration contiennent des données sensibles. Leur accès doit donc être protégé par des listes de contrôle d'accès correctement configurées.

Machine.config

Par défaut, Machine.config est assorti de la liste de contrôle d'accès suivante :

Administrateurs : Contrôle total
Système : Contrôle total
Utilisateurs avec pouvoir : Modification	
Utilisateurs : Lecture et exécution
LocalMachine\ASPNET (identité de processus) : Lecture et exécution

Remarque : sur Windows Server 2003, les comptes Service local et Service réseau bénéficient également d'un accès en lecture.

Les membres du groupe Utilisateurs bénéficient par défaut d'un accès en lecture, puisque l'ensemble du code géré exécuté sur l'ordinateur doit être en mesure de lire Machine.config.

La liste de contrôle d'accès de Machine.config est configurée pour assurer un bon niveau de sécurité. Si, toutefois, une seule application Web s'exécute sur le serveur, ou que toutes les applications Web utilisent la même identité de processus, vous pouvez restreindre encore davantage la liste de contrôle d'accès en supprimant l'entrée de contrôle d'accès (ACE) de l'utilisateur. Si vous supprimez l'entrée « utilisateurs » de la liste DACL, vous devez ajouter explicitement l'identité du processus Web.

Web.config

Le .NET Framework n'installe aucun fichier Web.config. Si vous installez une application qui inclut son propre fichier Web.config, celui-ci hérite généralement sa liste de contrôle d'accès du répertoire inetpub, lequel accorde par défaut un accès en lecture aux membres du groupe Tout le monde. Pour verrouiller un fichier Web.config spécifique à une application, utilisez l'une des listes de contrôle d'accès ci-dessous.

Pour .NET Framework version 1.0 :

Administrateurs : Contrôle total
Système : Contrôle total
Identité du processus ASP.NET : Lecture	
Identité UNC : Lecture
Identité représentée (identité prédéfinie) : Lecture
Identité représentée (appelant initial) : Lecture

Pour .NET Framework version 1.1 :

Administrateurs : Contrôle total
Système : Contrôle total
Identité de processus ASP.NET : Lecture
Identité UNC : Lecture
Identité représentée (identité prédéfinie) : Lecture

Si vos applications ont recours à l'emprunt d'identité en utilisant un compte explicite (si elles empruntent une identité prédéfinie), comme dans l'exemple : <identity impersonate="true" username="WebUser" password="Y0urStr0ngPassw0rd$"/>, alors le compte (WebUser, dans cet exemple) et le processus ont tous deux besoin d'un accès en lecture.

Si votre code est basé sur un partage UNC (Universal Naming Convention), vous devez accorder l'accès en lecture à l'identité du jeton UNC fourni par IIS.

Si vous avez recours à l'emprunt d'identité mais sans utiliser d'informations d'authentification explicites, comme dans l'exemple : <identity impersonate="true"/>, ni l'UNC, alors seul le processus doit bénéficier d'un accès en lecture sur le .NET Framework 1.1. Pour .NET Framework 1.0, vous devez également configurer la liste de contrôle d'accès de manière à accorder un accès en lecture à toute identité représentée (ce qui signifie que vous devez accorder un accès en lecture à l'appelant initial).

Niveaux de confiance dans ASP.NET

Le niveau de confiance d'une application détermine les autorisations que la stratégie de sécurité d'accès au code lui accorde. Il définit les ressources sécurisées auxquelles l'application peut accéder et les opérations privilégiées qu'elle a le droit de réaliser.

<trust>

Utilisez l'élément <trust> pour configurer le niveau de confiance de l'application. Par défaut, le niveau de confiance est défini sur Full (total), comme indiqué ci-dessous :

<!--  niveau="[Full|High|Medium|Low|Minimal]" -->
<trust level="Full" originUrl=""/>  

Cela signifie que l'application bénéficie de toutes les autorisations de la stratégie d'accès au code, sans aucune restriction. Dans cette configuration, la réussite ou l'échec des tentatives d'accès aux ressources opérées par l'application dépend uniquement de la sécurité définie au niveau du système d'exploitation.

Si vous définissez un niveau de confiance autre que Full (totale), vous risquez d'interrompre le fonctionnement d'applications Web ASP.NET existantes, selon le type de ressources auxquelles elles ont besoin d'accéder et les opérations qu'elles réalisent. Vous devez tester minutieusement toutes les applications à chaque fois que vous changez le niveau de confiance.

Pour plus d'informations sur la création d'applications Web à confiance partielle utilisant la sécurité d'accès au code, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ». Pour plus d'informations sur l'utilisation de niveaux de confiance à des fins d'isolation d'application, reportez-vous au module 20, « Hébergement de plusieurs applications ASP.NET ».

Identité de processus ASP.NET

Les applications et les services Web ASP.NET s'exécutent dans une instance partagée du processus de traitement ASP.NET (Aspnet_wp.exe). Les paramètres de niveau processus, dont l'identité de processus, sont configurés dans l'élément <processModel> de Machine.config.

<processModel>

L'identité du processus de traitement ASP.NET est définie dans les attributs userName et password de l'élément <processModel>. Pour configurer l'identité de processus, vous devez :

  • utiliser le compte ASPNET par défaut ;

  • utiliser un compte configuré sur le principe du « moindre privilège » ;

  • crypter les informations d'authentification <processModel> ;

  • ne pas lancer ASP.NET avec le compte SYSTÈME.

Utiliser le compte ASPNET par défaut

Le compte ASPNET local est un compte doté de privilèges limités, configuré par défaut pour l'exécution des applications et des services Web ASP.NET. Si vous pouvez utiliser ce compte, appliquez la configuration par défaut suivante :

<processModel enable="true" userName="machine" password="AutoGenerate" ... /> 
Utiliser un compte configuré sur le principe du « moindre privilège » ;

Si vous devez utiliser une autre identité pour exécuter le processus de traitement ASP.NET, veillez à ce qu'elle possède des privilèges aussi limités que possible. Vous limiterez ainsi les dommages que pourrait causer un pirate réussissant à exécuter du code dans le contexte de sécurité du processus.

Le choix d'utiliser un autre compte peut être dicté par la nécessité de se connecter à une base de données Microsoft SQL Server? ou à une ressource réseau impliquant l'authentification Windows. Sachez que vous pouvez utiliser le compte ASPNET local à cette fin. Pour plus d'informations, reportez-vous à la section « Accès aux données » plus loin dans ce module.

Pour plus d'informations sur les autorisations NTFS requises par le compte de processus ASP.NET, reportez-vous à la section « Listes de contrôle d'accès et autorisations » plus loin dans ce module.

Vous devez également attribuer les droits d'utilisateur suivants aux comptes de processus ASP.NET :

  • accéder à cet ordinateur à partir du réseau ;

  • ouvrir une session en tant que tâche ;

  • ouvrir une session en tant que service ;

  • refuser les ouvertures de session locales ;

  • interdire l'ouverture de session par les services Terminal Server.

Crypter les informations d'authentification <processModel>

Si vous devez utiliser un compte configuré, ne stockez pas les informations d'authentification en clair dans Machine.config. Utilisez l'utilitaire Aspnet_setreg.exe pour stocker les informations d'authentification sous forme cryptée dans le Registre.

  • Pour crypter les informations d'authentification définies dans <processModel> :

    1. A l'invite, tapez la commande suivante :

      aspnet_setreg -k:Software\YourApp\process -u:CustomAccount :p:StrongPassword
      

      Les informations d'authentification cryptées sont stockées dans la clé de Registre spécifiée, laquelle est protégée par une liste de contrôle d'accès restreinte qui accorde le contrôle total aux comptes Système, Administrateurs et Créateur propriétaire.

    2. Modifiez la configuration de l'élément <processModel> en ajoutant les attributs userName et password suivants :

      <processModel
      userName="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,userName"
      userName="registry:HKLM\SOFTWARE\YourApp\process\ASPNET_SETREG,userName"
      

Reportez-vous à l'article 329290 de la Base de connaissances Microsoft, « COMMENT FAIRE : Utilisation de l'utilitaire ASP.NET pour crypter les informations d'authentification et les chaînes de connexion de l'état de session ».

Ne pas lancer ASP.NET avec le compte SYSTÈME

N'utilisez pas le compte SYSTÈME pour exécuter ASP.NET et n'accordez pas le droit d'utilisateur « Agir en tant que partie du système d'exploitation » au compte de processus ASP.NET. Cela irait à l'encontre du principe du moindre privilège et augmenterait les dommages que pourrait causer un pirate réussissant à exécuter du code dans le contexte de sécurité du processus de l'application Web.

Emprunt d'identité

Par défaut, les applications ASP.NET n'effectuent pas d'emprunt d'identité. Le contexte de sécurité utilisé pour l'accès de l'application aux ressources Windows est celui du compte du processus de traitement ASP.NET (par défaut, ASPNET).

<identity>

L'élément <identity> permet d'activer l'emprunt d'identité. Vous pouvez emprunter les identités suivantes :

  • l'appelant initial (l'identité authentifiée par IIS) ;

  • une identité prédéfinie.

Emprunt de l'identité de l'appelant initial

Pour emprunter l'identité de l'appelant initial, utilisez la configuration suivante :

<identity impersonate="true" />

L'emprunt d'identité utilise le jeton d'accès fourni par IIS. Ce jeton représente l'appelant authentifié. Il peut s'agir du compte utilisateur Internet anonyme, par exemple, si votre application utilise l'authentification par formulaire, ou le compte Windows de l'appelant initial, si votre application utilise l'authentification Windows.

Avant de décider d'activer l'emprunt d'identité de l'appelant initial, notez ce qui suit :

  • L'évolutivité de l'application s'en trouve réduite par l'impossibilité de regrouper efficacement les connexions de base de données.

  • La charge d'administration augmente, car les listes de contrôle d'accès des ressources principales doivent être configurées en fonction de chaque utilisateur.

  • La délégation requiert l'authentification Kerberos et un environnement Windows 2000 correctement configuré.

Pour plus d'informations, reportez-vous à « How To: Implement Kerberos Delegation for Windows 2000" dans la section « How To » du guide « Microsoft patterns & practices Volume I, Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication » à l'adresse http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT05.asp.

Emprunt d'une identité prédéfinie

Pour emprunter une identité prédéfinie, spécifiez l'identité dans les attributs userName et password de l'élément <identity> :

<identity impersonate="true" userName="MyServiceAccount" 
                             password="Str0ng!Passw0rd"/>

Ne stockez pas les informations d'authentification en clair comme ci-dessus. Utilisez plutôt l'outil Aspnet_setreg.exe pour crypter les informations d'authentification et les stocker dans le Registre.

  • Pour crypter les informations d'authentification définies dans <identity> :

    1. A l'invite, tapez la commande suivante :

      aspnet_setreg -k:Software\YourApp\identity -u:CustomAccount :p:StrongPassword
      

      Les informations d'authentification cryptées dans stockées dans la clé de Registre spécifiée, laquelle est protégée par une liste de contrôle d'accès restreinte qui accorde le contrôle total aux comptes Système, Administrateurs et Créateur propriétaire.

    2. Modifiez la configuration de l'élément <identity> en ajoutant les attributs userName et password suivants :

      <identity impersonate="true"
      userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"
      password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>
      
    3. Utilisez Regedt32.exe pour appliquer une liste de contrôle d'accès à la clé de Registre ci-dessus, afin d'accorder un accès en lecture au compte du processus ASP.NET.

Reportez-vous à l'article 329290 de la Base de connaissances Microsoft, « COMMENT FAIRE : Utilisation de l'utilitaire ASP.NET pour crypter les informations d'authentification et les chaînes de connexion de l'état de session ».

Agir en tant que partie du système d'exploitation

Pour activer l'emprunt d'une identité prédéfinie en définissant les attributs userName et password dans ASP.NET version 1.0, le compte de processus doit posséder le droit d'utilisateur « Agir en tant que partie du système d'exploitation » de Windows 2000. Étant donné que le compte de processus ASP.NET se voit ainsi accorder un niveau de privilèges proche de celui du compte Système local, l'emprunt d'une identité prédéfinie n'est pas recommandé dans ASP.NET version 1.0.

Remarque : ce droit d'utilisateur n'est pas requis si vous exécutez ASP.NET version 1.1 sur Windows 2000 ou Windows Server 2003.

Autorisations NTFS requises

Les identités représentées doivent posséder les autorisations NTFS appropriées. Pour plus d'informations, reportez-vous à la section « Listes de contrôle d'accès et autorisations » plus loin dans ce module.

Authentification

L'élément <authentication> configure le mode d'authentification de l'application.

<authentication>

Le mode d'authentification à employer dépend de la façon dont l'application ou le service Web ont été conçus. Le paramètre Machine.config par défaut applique un mode d'authentification sûr, comme illustré ci-dessous.

<!-- attributs d'authentification :
     mode="[Windows|Forms|Passport|None]" -->
<authentication mode="Windows"/>

Instructions d'utilisation de l'authentification par formulaire

Pour utiliser l'authentification par formulaire, définissez mode="Forms" dans l'élément <authentication>. Ensuite, configurez l'authentification par formulaire à l'aide de l'élément enfant <forms>. L'exemple suivant présente une configuration sécurisée de l'élément d'authentification <forms>.

<authentication mode="Forms"> 
  <forms loginUrl="Restricted\login.aspx"  Page de connexion dans un dossier protégé par SSL
         protection="All"                  Confidentialité et intégrité
         requireSSL="true"                 Empêche le cookie d'être envoyé via http
         timeout="10"                      Durée de vie de la session limitée
         name="AppNameCookie"              Nom
         path="/FormsAuth"                    et chemin uniques pour chaque application
         slidingExpiration="true" >        Durée de vie de la session décalée
  </forms>
</authentication>

Suivez les recommandations suivantes pour améliorer la sécurité de l'authentification par formulaire :

  • partitionner le site Web ;

  • définir la directive protection="All" ;

  • utiliser des valeurs d'expiration de cookie réduites ;

  • utiliser éventuellement un délai d'expiration fixe ;

  • utiliser SSL avec l'authentification par formulaire ;

  • si SSL n'est pas utilisé, définir la directive slidingExpiration = "false" ;

  • ne pas utiliser l'élément <credentials> sur des serveurs de production ;

  • configurer l'élément <machineKey> ;

  • choisir des noms de cookies et de chemins uniques.

Partitionner le site Web

Séparez les zones publiques des zones à accès restreint sur votre site Web. Placez la page de connexion à votre application, ainsi que les autres pages et les autres ressources accessibles uniquement aux utilisateurs authentifiés dans un dossier séparé des zones publiques. Protégez les sous-dossiers à accès restreint dans IIS en spécifiant un accès SSL, puis utilisez les éléments <authorization> pour restreindre l'accès et forcer l'ouverture de session. Dans la configuration Web.config ci-dessous, par exemple, tout le monde peut accéder au répertoire en cours (c'est l'accès public), mais seuls les utilisateurs authentifiés ont le droit d'accéder au sous-dossier protégé. Toute tentative d'accès par un utilisateur non authentifié affiche une page de connexion par formulaire.

<system.web> 
  <!-- Le dossier racine de répertoire virtuel contient les pages générales.
       Les utilisateurs non authentitifiés peuvent les afficher et elles n'ont pas besoin d'être 
       sécurisées à l'aide de SSL. -->
  <authorization>
    <allow users="*" />
  </authorization>
</system.web>

<!-- Le dossier restreint est réservé à l'accès authentifié et à l'accès SSL. -->
<location path="Restreint" >
  <system.web> 
    <authorization>
      <deny users="?" />
    </authorization>
  </system.web>
</location>

Pour plus d'informations sur les aspects de programmation, par exemple sur la manière de passer des pages à accès restreint aux pages à accès public, reportez-vous à la section « Authentification par formulaire » du module 10, « Création de pages Web et de contrôles ASP.NET ».

Définir la directive protection="All" 

Ce paramètre permet de garantir que le cookie d'authentification par formulaire soit crypté, afin de préserver la confidentialité et l'intégrité. Les clés et les algorithmes utilisés pour crypter le cookie sont définis dans l'élément <machineKey>.

Le cryptage et les contrôles d'intégrité empêchent la falsification des cookies, mais ils ne réduisent pas le risque d'attaque par relecture de cookie si un pirate réussit à intercepter le cookie. Utilisez également SSL pour éviter le risque qu'un pirate parvienne à intercepter le cookie en s'aidant d'un logiciel de surveillance du réseau. En dépit de SSL, il reste un risque de vol des cookies par attaque de script inter-sites. Il est impératif que l'application prenne les précautions appropriées en appliquant une bonne stratégie de validation de la saisie afin de limiter ce risque.

Utiliser des valeurs d'expiration de cookie réduites

Utilisez des valeurs d'expiration de cookie réduites pour limiter la durée de vie de la session et réduire les risques d'attaque par relecture de cookie.

Utiliser éventuellement un délai d'expiration fixe

Vous pouvez déclarer l'attribut slidingExpiration="false" dans l'élément <forms> afin de définir un délai fixe d'expiration de cookie, plutôt que de le réinitialiser après chaque requête de page. C'est une mesure importante si vous n'utilisez pas SSL pour protéger le cookie.

Remarque : cette fonctionnalité est disponible dans .NET Framework version 1.1.

Utiliser SSL avec l'authentification par formulaire

Utilisez SSL pour protéger les informations d'authentification et le cookie d'authentification. Le protocole SSL empêche les pirates d'intercepter les informations d'authentification ou le cookie d'authentification par formulaire servant à vous identifier auprès de l'application. Un cookie d'authentification volé équivaut à une connexion volée.

Spécifiez requireSSL="true". Vous définissez ainsi l'attribut Secure dans le cookie, ce qui garantit que le navigateur ne transmettra pas le cookie au serveur par une liaison HTTP. Une connexion HTTPS (SSL) est requise.

Remarque : il s'agit d'un paramètre .NET Framework version 1.1. Dans les applications basées sur la version 1.0, la définition de l'attribut Secure du cookie demande une programmation spécifique. Pour plus d'informations et des exemples de code, reportez-vous au module 10, « Création de pages Web et de contrôles ASP.NET ».

Si SSL n'est pas utilisé, définir la directive slidingExpiration = "false"

Lorsque slidingExpiration est défini sur false, le délai d'expiration du cookie est fixé à un certain nombre de minutes à compter de la création initiale du cookie. Dans le cas contraire, le délai d'expiration est remis à zéro à chaque demande transmise au serveur Web. Si un pirate parvient à intercepter le cookie, il dispose alors de tout le temps nécessaire pour accéder à l'application comme s'il était un utilisateur authentifié.

Remarque : cette fonctionnalité est disponible dans .NET Framework version 1.1.

Ne pas utiliser l'élément <credentials> sur des serveurs de production

La possibilité de stocker les informations d'authentification utilisateur dans des fichiers de configuration XML est offerte pour accélérer le développement et limiter les tests. N'utilisez pas les informations d'authentification des utilisateurs finaux. Les informations d'authentification des utilisateurs finaux ne doivent pas être stockées dans des fichiers de configuration sur les serveurs de production. Les applications de production doivent recourir à des magasins personnalisés pour stocker les informations d'authentification utilisateur, dans une base de données SQL Server par exemple.

Configurer l'élément MachineKey

L'élément <machineKey> définit les algorithmes de cryptage utilisés pour crypter le cookie d'authentification par formulaire. Cet élément gère également les clés de cryptage. Pour plus d'informations, reportez-vous à la section « Clé ordinateur » de ce module.

Choisir des noms de cookies et de chemins uniques

Choisissez des valeurs d'attribut name et path uniques. Veillez à ce que les noms utilisés soient uniques pour éviter tout problème pouvant survenir lorsque plusieurs applications sont hébergées sur le même serveur.

Autorisation

Par défaut, la configuration doit refuser l'accès aux ressources pour lesquelles l'utilisateur ne dispose pas d'autorisation explicite, comme un page Web, un fichier de ressources, un répertoire, etc. ASP.NET fournit deux opérateurs de contrôle d'appels que vous pouvez utiliser pour contrôler l'accès aux ressources protégées. Il s'agit de :

  • L'autorisation d'accès au fichier. Cet opérateur de contrôle d'appels est implémenté par le module HTTP
    FileAuthorizationModule d'ASP.NET.

  • L'autorisation d'accès à l'URL. Cet opérateur de contrôle d'appels est implémenté par le module HTTP
    UrlAuthorizationModule d'ASP.NET.

Autorisation d'accès au fichier

Seules les applications utilisant l'authentification Windows et dotées de la configuration suivante peuvent utiliser cet opérateur de contrôle d'appels :

<authentication mode="Windows"/>

Il s'active automatiquement lorsque vous utilisez l'authentification Windows et ne nécessite pas l'emprunt d'identité. Pour configurer l'opérateur de contrôle d'appels, configurez les listes de contrôle d'accès Windows sur les fichiers et les dossiers. Notez que l'opérateur de contrôle d'appels gère uniquement l'accès aux types de fichiers qu'IIS a mappé sur l'extension ISAPI ASP.NET suivante : Aspnet_isapi.dll.

Autorisation d'accès à l'URL

Toutes les applications peuvent utiliser cet opérateur de contrôle d'appels. Il se configure à l'aide des éléments <authorization> qui contrôlent l'accès des utilisateurs et des groupes à l'application. Par défaut, l'élément est défini dans Machine.config comme suit :

<authorization>
  <!-- attributs d'autorisation/d'interdiction :
     users="[*|?|name]"
        * - All users
        ? - Anonymous users
        [name] - Named user
     roles="[name]" -->
 <allow users="*" />
</authorization>
Remarques relatives à l'autorisation d'accès à l'URL

Tenez compte des éléments suivants pour configurer correctement l'autorisation d'accès à l'URL :

  • Les paramètres d'autorisation de Web.config concernent généralement tous les fichiers contenus dans le répertoire en cours et dans tous ses sous-répertoires, à moins qu'un sous-répertoire contienne son propre fichier Web.config comprenant un élément <authorization>. Dans ce cas, les paramètres définis dans le sous-répertoire remplacent ceux du répertoire parent.

  • L'autorisation d'accès à l'URL s'applique uniquement aux types de fichiers qu'IIS a mappé sur l'extension ISAPI ASP.NET suivante : Aspnet_isapi.dll.

  • Si votre application utilise l'authentification Windows, vous autorisez l'accès à des comptes d'utilisateurs et de groupes Windows. Les noms d'utilisateurs prennent la forme « autorité\NomUtilisateurWindows » et les noms de rôles, « autorité\NomGroupeWindows », l'autorité correspondant soit à un nom de domaine, soit au nom de l'ordinateur local, selon le type de compte.

    Un certain nombre de comptes connus sont représentés par des chaînes « BUILTIN ». Par exemple, le groupe Administrateurs local est désigné par « BUILTIN\Administrators ». Le groupe Utilisateurs locaux est désigné par « BUILTIN\Users ».

    Remarque : dans .NET Framework version 1.0, le nom de l'autorité et du groupe respectent la casse. Le nom de groupe doit correspondre exactement à celui défini dans Windows.

  • Si votre application utilise l'authentification par formulaire, vous autorisez les utilisateurs et les rôles spécifiés dans votre propre magasin d'utilisateurs. Par exemple, si vous utilisez des formulaires pour authentifier les utilisateurs par rapport aux informations stockées dans une base de données, vous définissez leurs autorisations par rapport aux rôles trouvés dans la base de données.

  • Vous pouvez utiliser la balise <location> pour associer des paramètres d'autorisation à un fichier ou à un répertoire donné. L'exemple qui suit montre comment appliquer des paramètres d'autorisation à un fichier spécifique (page.aspx) :

    <location path="page.aspx" />
      <authorization>
        <allow users="NomDomaine\Bernard, NomDomaine\Marie" />
        <deny users="*" />
      </authorization>
    </location>

État de session

Les applications qui utilisent l'état de session utilisateur peuvent stocker les informations d'état de session aux emplacements suivants :

  • dans le processus de traitement ASP.NET ;

  • dans un service d'état hors processus, exécuté sur le serveur Web ou sur un serveur distant ;

  • dans un magasin de données SQL Server.

<sessionState>

L'emplacement approprié et les informations de connexion sont spécifiés dans l'élément <sessionState> de Machine.config. Le paramètre par défaut est le suivant :

<sessionState mode="InProc"
              stateConnectionString="tcpip=127.0.0.1:42424" 
              stateNetworkTimeout="10" sqlConnectionString="data 
              source=127.0.0.1;Integrated Security=SSPI" 
              cookieless="false" timeout="20"/>

Remarque : si vous n'utilisez pas le service d'état ASP.NET sur le serveur Web, utilisez le composant logiciel enfichable MMC pour le désactiver.

Sécurisation d'un magasin d'état de session SQL Server

Si vous utilisez un magasin d'état de session SQL Server, suivez les recommandations suivantes pour sécuriser l'état de session :

  • utiliser l'authentification Windows pour la base de données ;

  • crypter sqlConnectionString ;

  • limiter les droits de l'application dans la base de données ;

  • sécuriser le canal.

Pour plus d'informations sur la configuration de la base de données du magasin d'état de session SQL Server, consultez l'article 311209 de la base de connaissances Microsoft intitulé « Comment faire : Configurer SQL Server pour stocker un état de session ASP.NET ».

Utiliser l'authentification Windows pour la base de données

Si vous déclarez l'attribut mode="SQLServer", utilisez l'authentification Windows pour la connexion à la base de données d'état et choisissez un compte peu privilégié, comme une copie locale du compte ASPNET. Ainsi, vous pourrez utiliser une connexion sécurisée, les informations d'authentification ne figureront pas dans la chaîne de connexion et ne seront pas transmises sur le canal menant à la base de données.

Crypter la valeur d'attribut sqlConnectionString

Cryptez la valeur d'attribut sqlConnectionString à l'aide de l'outil Aspnet_setreg.exe. Cette mesure est particulièrement importante si vous utilisez l'authentification SQL pour la connexion à la base de données car les informations d'authentification sont alors incluses dans la chaîne de connexion, mais elle est aussi conseillée si vous utilisez l'authentification Windows.

  • Pour crypter la valeur d'attribut sqlConnectionString :

    1. A l'invite, tapez la commande suivante :

      aspnet_setreg -k:Software\YourApp\sessionState -c:{your connection string}
      

      La chaîne de connexion cryptée est stockée dans la clé de Registre spécifiée, laquelle est protégée par une liste de contrôle d'accès restreinte qui accorde le contrôle total aux comptes Système, Administrateurs et Créateur propriétaire.

    2. Reconfigurez l'élément <sessionState> et ajoutez l'attribut sqlConnectionString suivant :

      <sessionState mode="SQLServer"
      sqlConnectionString="registry:HKLM\SOFTWARE\YourApp\sessionState
      \ASPNET_SETREG,sqlConnectionString" />
      
    3. Utilisez Regedt32.exe pour appliquer une liste de contrôle d'accès à la clé de Registre ci-dessus, afin d'accorder un accès en lecture au compte du processus ASP.NET.

Limiter les droits de l'application dans la base de données

Le compte utilisé par l'application pour se connecter à la base de données doit seulement lui permettre d'accéder aux tables d'état et aux procédures stockées qu'ASP.NET utilise pour interroger la base de données.

  • Pour limiter les droits de l'application dans la base de données d'état :

    1. Sur le serveur de base de données d'état, créez une copie locale du compte servant à exécuter l'application ASP.NET, en gardant le même nom et le même mot de passe sûr.

      Pour plus d'informations sur l'utilisation du compte ASPNET pour accéder à une base de données distante, reportez-vous à la section « Accès aux données«  plus loin dans ce module.

    2. Créez un groupe Windows local sur le serveur de base de données, ASPNETWebApps par exemple, et ajoutez-lui le compte ASPNET local.

    3. Accordez au groupe Windows l'accès à SQL Server en créant un nouveau compte de connexion.

      sp_grantlogin 'MACHINE\ASPNETWebApps'

      Remarque : remplacez MACHINE par le nom de votre serveur de base de données.

    4. Accordez au compte de connexion SQL l'accès à la base de données ASPState. Le code T-SQL suivant crée un utilisateur de base de données appelé WebAppUser, auquel le compte de connexion est associé.

      USE ASPState
      GO
      sp_grantdbaccess 'MACHINE\ASPNETWebApps', 'WebAppUser'
      
    5. Créez un rôle de base de données défini par l'utilisateur.

      USE ASPState
      GO
      sp_addrole 'WebAppUserRole'
      
    6. Ajoutez l'utilisateur de base de données au nouveau rôle de base de données.

      USE ASPState
      GO
      sp_addrolemember 'WebAppUserRole', 'WebAppUser'
      
    7. Dans la base de données, configurez les autorisations du rôle de base de données. Accordez les autorisations d'exécution aux procédures stockées fournies avec la base de données ASPState.

      grant execute on CreateTempTables to WebAppUserRole
      

      Répétez cette commande pour toutes les procédures stockées fournies avec la base de données ASPState. Utilisez SQL Server Enterprise Manager pour en visualiser la liste complète.

Sécuriser le canal

Afin de protéger les données sensibles d'état de session sur le réseau entre le serveur Web et le magasin d'état distant, sécurisez le canal vers les deux serveurs à l'aide des méthodes IPSec ou SSL. Vous garantirez ainsi la confidentialité et l'intégrité des données d'état de session sur le réseau. Si vous utilisez SSL, vous devez installer un certificat de serveur sur le serveur de base de données. Pour plus d'informations sur l'utilisation de SSL avec SQL Server, reportez-vous au module 18, « Sécurisation de votre serveur de base de données« .

Sécurisation du service d'état hors processus

Si vous déclarez l'attribut mode=StateServer, suivez les recommandations suivantes pour sécuriser l'état de session :

  • utiliser un compte configuré sur le principe du « moindre privilège » pour exécuter le service d'état ;

  • sécuriser le canal ;

  • modifier éventuellement le port par défaut ;

  • crypter la chaîne de connexion d'état.

Utiliser un compte configuré sur le principe du « moindre privilège » pour exécuter le service d'état

Par défaut, le service d'état s'exécute à partir du compte ASPNET local doté du minimum de privilèges. En principe, il n'est pas nécessaire de modifier cette configuration.

Sécuriser le canal

Si le service d'état est situé sur un serveur distant, sécurisez le canal vers le magasin d'état distant à l'aide du protocole IPSec afin de garantir la confidentialité et l'intégrité de l'état utilisateur.

Modifier éventuellement le port par défaut

Le service d'état ASP.NET écoute le port 42424. Pour ne pas utiliser ce port par défaut trop bien connu, vous pouvez modifier la clé de Registre suivante :

HKLM\SYSTEM\CurrentControlSet\Services\aspnet_state\Parameters

Le numéro de port est défini par la valeur nommée Port. Si vous modifiez le numéro de port dans le Registre, pour utiliser par exemple le port 45678, vous devez également modifier la chaîne de connexion dans l'élément <sessionState>, comme suit :

stateConnectionString="tcpip=127.0.0.1:45678" 
Crypter la valeur d'attribut stateConnectionString

Cryptez la valeur d'attribut stateConnectionString pour masquer l'adresse IP et le numéro de port de votre magasin d'état. Utilisez l'outil Aspnet_setreg.exe.

  • Pour crypter la valeur d'attribut stateConnectionString :

    1. A l'invite, tapez la commande suivante :

      aspnet_setreg -k:Software\YourApp\sessionState -d:{your connection string}
      

      La chaîne de connexion cryptée est stockée dans la clé de Registre spécifiée, laquelle est protégée par une liste de contrôle d'accès restreinte qui accorde le contrôle total aux comptes Système, Administrateurs et Créateur propriétaire.

    2. Reconfigurez l'élément <sessionState> et ajoutez l'attribut stateConnectionString suivant :

      <sessionState mode="StateServer"
      sqlConnectionString="registry:HKLM\SOFTWARE\YourApp\sessionState
      \ASPNET_SETREG,sqlConnectionString" ... />
      
    3. Utilisez Regedt32.exe pour appliquer une liste de contrôle d'accès à la clé de Registre ci-dessus, afin d'accorder un accès en lecture au compte du processus ASP.NET.

État d'affichage

Si votre application utilise l'état d'affichage, veillez à le protéger par des codes d'authentification de message (MAC) pour éviter toute modification côté client. Vous pouvez activer et désactiver l'état d'affichage et la protection MAC pour toutes les applications de l'ordinateur dans l'élément <pages> de Machine.config.

<pages>

Par défaut, l'attribut enableViewStateMac de l'élément <pages> dans Machine.config est configuré pour protéger l'état d'affichage par un code d'authentification de message.

<pages buffer="true" enableSessionState="true"
       enableViewState="true" enableViewStateMac="true" 
       autoEventWireup="true" validateRequest="true"/>

Si vous utilisez l'état d'affichage, veillez à ce que enableViewStateMac soit défini sur true. L'élément <machineKey> définit les algorithmes servant à protéger l'état d'affichage.

Clé ordinateur

L'élément <machineKey> permet de spécifier les clés de cryptage, les clés de validation et les algorithmes utilisés pour protéger les cookies d'authentification et l'état d'affichage au niveau de chaque page. L'exemple de code ci-dessous illustre la configuration par défaut de Machine.config :

<machineKey validationKey="AutoGenerate,IsolateApps" 
            decryptionKey="AutoGenerate,IsolateApps" validation="SHA1"/>

Tenez compte des recommandations suivantes pour configurer l'élément <machineKey> :

  • utiliser des clés de cryptage uniques pour chaque application ;

  • définir l'attribut validation="SHA1" ;

  • générer manuellement les clés pour les batteries de serveurs.

Utiliser des clés de cryptage uniques pour chaque application

Si vous hébergez plusieurs applications sur un même serveur Web, utilisez des clés uniques pour chaque application de l'ordinateur plutôt qu'une même clé valable pour toutes les applications. Vous éviterez ainsi le risque qu'une application usurpe l'état d'affichage ou les cookies cryptés de l'authentification par formulaire dans les environnements d'hébergement.

Utilisez aussi le paramètre IsolateApps. Il s'agit d'un nouveau paramètre de .NET Framework version 1.1 qui demande à ASP.NET de générer automatiquement des clés de cryptage et de les rendre uniques pour chaque application.

Définir l'attribut validation="SHA1"

L'attribut validation définit l'algorithme utilisé pour vérifier l'intégrité de l'état d'affichage au niveau de chaque page. Les valeurs possibles sont : "SHA1", "MD5" et "3DES".

Si vous avez défini l'attribut protection="All" dans l'élément <forms>, le cookie d'authentification par formulaire est crypté, ce qui garantit également l'intégrité. Quelle que soit la valeur de l'attribut validation, l'authentification par formulaire utilise l'algorithme Triple-DES (3DES) pour crypter le cookie.

Remarque : le cryptage du cookie d'authentification par formulaire est indépendant du paramètre validationkey. La clé est basée sur l'attribut decryptionKey.

Si vous déclarez l'attribut validation="SHA1" dans l'élément <machineKey>, l'intégrité de l'état d'affichage des pages est vérifié à l'aide de l'algorithme SHA1, en supposant que l'élément <pages> est configuré pour l'utilisation de codes d'authentification de message d'état d'affichage. Pour plus d'informations, reportez-vous à la section « État d'affichage » abordée précédemment dans ce module.

Vous pouvez également définir l'attribut de validation sur MD5. Il est recommandé d'utiliser l'algorithme SHA1 car celui-ci renvoie une valeur plus longue que le MD5 ; il est donc jugé plus sûr.

Si vous déclarez l'attribut validation="3DES" dans l'élément <machineKey>, l'état d'affichage des pages est crypté (ce qui assure également le contrôle d'intégrité) à l'aide de l'algorithme 3DES, même si l'élément <pages> est configuré pour l'utilisation de codes d'authentification de message d'état d'affichage.

Générer manuellement les clés pour les batteries de serveurs

Dans les batteries de serveurs Web, vous devez définir des valeurs de clé explicites et utiliser les mêmes valeurs sur tous les ordinateurs de la batterie de serveurs Web. Reportez-vous à la section « Considérations relatives aux batteries de serveurs Web » plus loin dans ce module.

Débogage

L'élément <compilation> contrôle les paramètres de compilateur utilisés pour la compilation des pages dynamiques, lancée à chaque fois qu'un client demande une page Web (fichier .aspx) ou un service Web (fichier .asmx). Il est crucial que les versions debug ne soient pas utilisées sur le serveur de production car les informations de débogage sont très utiles aux éventuels pirates et peuvent révéler le contenu du code source.

<compilation>

Cet élément contrôle le processus de compilation. Vérifiez que le mode débogage est désactivé sur les serveurs de production. Déclarez l'attribut debug="false" comme suit :

<compilation debug="false" explicit="true" defaultLanguage="vb" />

Par défaut, les fichiers temporaires sont créés et compilés dans le répertoire suivant :

%winnt%\Microsoft.NET\Framework\{version}\Temporary ASP.NET Files

Vous pouvez spécifier un emplacement différent pour chaque application, grâce à l'attribut tempDirectory, mais cela ne renforce en rien la sécurité.

Remarque : l'identité de processus ASP.NET spécifiée dans l'élément <processModel> doit posséder des droits d'accès avec contrôle total sur le répertoire de compilation temporaire.

Veillez à ne pas stocker les fichiers des versions debug (avec l'extension .pdb) sur un serveur de production, avec vos assemblys.

Traçage

N'activez pas le traçage sur les serveurs de production car les informations de traçage au niveau système peuvent considérablement aider les pirates à profiler une application et à en sonder les vulnérabilités.

<trace>

Le traçage se configure dans l'élément <trace>. Déclarez l'attribut enabled="false" sur les serveurs de production, comme indiqué ci-dessous :

<trace enabled="false" localOnly="true" pageOutput="false" 
       requestLimit="10" traceMode="SortByTime"/>

Si vous n'avez pas besoin de dépanner une application en production, il est préférable de simuler le problème dans un environnement de test ou, si nécessaire, d'activer le traçage et de déclarer l'attribut localOnly="true" pour éviter que les informations de traçage soient renvoyées aux clients distants.

Gestion des exceptions

Ne laissez pas les informations relatives aux exceptions remonter depuis vos applications Web vers le client. Un utilisateur malveillant pourrait utiliser les informations de diagnostic au niveau système pour profiler l'application et en sonder les vulnérabilités en vue de préparer de futures attaques.

<customErrors>

L'élément <customErrors> peut servir à configurer des messages d'erreur génériques personnalisés à retourner au client si une condition d'erreur se produit dans l'application. La page d'erreur doit contenir un message d'erreur générique approprié, éventuellement accompagné d'informations relatives au support technique. Vous pouvez également utiliser cet élément pour renvoyer des pages d'erreur différentes selon la condition d'exception.

Vous devez pour cela définir l'attribut mode sur « On » et spécifier une page de redirection par défaut comme indiqué ci-dessous :

<customErrors mode="On" defaultRedirect="YourErrorPage.htm" />

L'attribut defaultRedirect vous permet d'utiliser une page d'erreur personnalisée pour votre application, indiquant par exemple comment contacter le support technique.

Remarque : ne déclarez pas l'attribut mode sur « Off », sinon le client recevra les pages d'erreur détaillées contenant les informations système.

Si vous souhaitez afficher différentes pages d'erreur en fonction du type d'erreur, utilisez un ou plusieurs éléments <error> comme indiqué dans l'exemple ci-dessous. Les erreurs « 404 (not found) » sont redirigées vers une page et les erreurs « 500 (internal system errors) » vers une autre. Toutes les autres erreurs sont dirigées vers la page indiquée dans l'attribut defaultRedirect.

<customErrors mode="On" defaultRedirect="YourErrorPage.htm">
   <error statusCode="404" redirect="YourNotFoundPage.htm"/>
   <error statusCode="500" redirect="YourInternalErrorPage.htm"/>
</customErrors>

Accès distant

N'exposez pas les points de terminaison de .NET Remoting sur des serveurs Web directement connectés à Internet. Pour désactiver l'accès distant, désactivez les demandes d'extension .rem et .soap en mappant ces demandes sur HttpForbiddenHandler. Déclarez les éléments suivants sous <httpHandlers> :

<httpHandlers>
  <add verb="*" path="*.rem" type="System.Web.HttpForbiddenHandler"/>
  <add verb="*" path="*.soap" type="System.Web.HttpForbiddenHandler"/>
  . . .
</httpHandlers>

Remarque : cela n'empêche pas une application Web hébergée sur le serveur Web de se connecter à un objet en aval en utilisant l'infrastructure .Net Remoting. Cependant, les clients ne peuvent plus se connecter aux objets du serveur Web.

Services Web

Configurez les services Web en utilisant l'élément <webServices>. Pour configurer les services Web de manière sécurisée, vous devez :

  • désactiver les services Web superflus ;

  • désactiver les protocoles inutilisés ;

  • désactiver la génération automatique de WSDL.

Désactiver les services Web superflus

Si vous n'utilisez pas certains services Web, désactivez-les en mappant les demandes portant sur l'extension de fichier .asmx (service Web) vers HttpForbiddenHandler dans Machine.config, comme indiqué ci-dessous :

<httpHandlers>
  <add verb="*" path="*.asmx" type="System.Web.HttpForbiddenHandler"/>
  . . .
</httpHandlers>

Désactiver les protocoles inutilisés

L'élément <protocols> définit les protocoles que les services Web prennent en charge. Par défaut, HttpPost et HttpGet sont désactivés dans .NET Framework version 1.1, comme dans l'exemple suivant :

<webServices>
  <protocols>
    <add name="HttpSoap1.2"/>
    <add name="HttpSoap"/>
    <!-- <add name="HttpPost"/> -->
    <!-- <add name="HttpGet"/> -->
    <add name="HttpPostLocalhost"/>
    <add name="Documentation"/>
  </protocols>
</webServices>

En désactivant les protocoles inutiles, notamment HttpPost et HttpGet, vous réduisez la surface exposée aux attaques. Par exemple, un pirate externe pourrait incorporer dans un message électronique un lien malveillant provoquant l'exécution d'un service Web interne dans le contexte de sécurité de l'utilisateur final. La désactivation du protocole HttpGet est une contre-mesure efficace. Cette attaque s'apparente beaucoup à une attaque XSS. Une variante de l'attaque utilise une balise <img src="..." /> sur une page Web accessible à tous pour incorporer un appel GET à un service Web de l'intranet. Les deux types d'attaque permettent à un utilisateur extérieur d'appeler un service Web interne. La désactivation des protocoles réduit ce risque.

Si votre serveur de production fournit des services Web pouvant être découverts publiquement, vous devez activer HttpGet et HttpPost pour permettre la découverte du service sur ces protocoles.

Désactiver la génération automatique de WSDL

Le protocole Documentation permet de générer automatique un fichier WSDL (Web Service Description Language). Le fichier WSDL décrit les caractéristiques d'un service Web, comme ses signatures de méthode et les protocoles qu'il prend en charge. Ces informations permettent aux clients de construire des messages au format approprié. Par défaut, les services Web exposent publiquement les fichiers WSDL, qui deviennent alors accessibles à toute personne capable de se connecter au serveur Web via Internet.

Dans certains cas, il peut être préférable de distribuer manuellement les fichiers WSDL à ses partenaires et d'empêcher l'accès public. Pour ce faire, l'équipe de développement peut fournir à l'équipe des opérations des fichiers .wsdl distincts pour chaque service Web. L'équipe des opérations les transmet ensuite aux partenaires qui souhaitent utiliser les services Web.

Pour désactiver le protocole Documentation, commentez-le dans le fichier Machine.config, comme suit :

<webServices>
  <protocols>
    <add name="HttpSoap"/>
    <!-- <add name="Documentation"/> -->
  </protocols>
</webServices>

Ressources protégées

Pour éviter que les ressources et les fichiers protégés puissent être téléchargés via HTTP, mappez-les sur le gestionnaire ASP.NET HttpForbiddenHandler.

Mapper les ressources protégées sur HttpForbiddenHandler

Les gestionnaires HTTP sont situés sous l'élément <httpHandlers> dans le fichier Machine.config. Les gestionnaires HTTP se chargent du traitement des requêtes Web portant sur des extensions de fichiers spécifiques. L'accès distant ne doit pas être activé sur les serveurs Web frontaux ; activez-le uniquement sur les serveurs d'application de couche intermédiaire isolés d'Internet.

  • Dans Machine.config, les extensions de fichier suivantes sont mappées sur des gestionnaires HTTP :

  • l'extension .aspx est utilisée pour les pages ASP.NET ;

  • les extensions .rem et .soap sont utilisées pour l'accès distant ;

  • l'extension .asmx est utilisée pour les services Web ;

  • les extensions .asax, .ascx, .config, .cs, .csproj, .vb, .vbproj, .webinfo, .asp, .licx, .resx et .resources correspondent à des ressources protégées, mappées sur System.Web.HttpForbiddenHandler.

En ce qui concerne les ressources .NET Framework, si vous n'utilisez pas d'extension de fichier, mappez l'extension sur System.Web.HttpForbiddenHandler dans Machine.config, comme indiqué dans l'exemple suivant :

<add verb="*" path="*.vbproj" type="System.Web.HttpForbiddenHandler" />

Dans cet exemple, l'extension de fichier .vbproj est mappée sur System.Web.HttpForbiddenHandler. Si un client demande un chemin qui se termine par .vbproj, ASP.NET renvoie le message « This type of page is not served ».

  • Suivez les instructions suivantes pour gérer les extensions de fichiers .NET Framework :

  • Mappez les extensions que vous n'utilisez pas sur HttpForbiddenHandler. Si vous n'avez aucune page ASP.NET, mappez l'extension .aspx sur HttpForbiddenHandler. Si vous n'utilisez aucun service Web, mappez l'extension .asmx sur HttpForbiddenHandler.

  • Désactivez l'accès distant sur les serveurs Web directement connectés à Internet. Mappez les extensions d'accès distant (.soap et .rem) des serveurs Web frontaux sur HttpForbiddenHandler.

Répertoire Bin

Le répertoire bin d'une application ASP.NET, situé sous son répertoire racine virtuel, contient les assemblys privés de l'application, y compris ses implémentations de la classe page si des fichiers code-behind ont été utilisés au cours du développement.

Sécuriser le répertoire Bin

Pour sécuriser le répertoire bin de l'application et éviter tout téléchargement involontaire de la logique métier, vous devez :

  • supprimer les autorisations Web ;

  • supprimer tous les paramètres d'authentification.

Supprimer les autorisations Web

Utilisez le composant logiciel enfichable IIS pour vous assurer que le répertoire bin ne contient pas d'autorisations Lecture, Écriture ou Exploration de répertoire. Vérifiez également que les autorisations Exécution sont définies sur Aucune.

Supprimer tous les paramètres d'authentification

Utilisez le composant logiciel enfichable IIS pour supprimer les paramètres d'authentification du répertoire bin. Tous les accès seront alors refusés.

Journal d'événements

Les comptes les moins privilégiés, comme le compte ASPNET, disposent des autorisations suffisantes pour consigner des enregistrements dans le journal d'événements à l'aide des sources d'événement existantes. Toutefois, ils ne peuvent pas créer de nouvelles sources d'événement. Pour ce faire, vous devez insérer une nouvelle entrée sous la clé de Registre suivante :

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog\<log>

Pour éviter de rencontrer le problème, vous pouvez créer des sources d'événement lors de l'installation, lorsque les privilèges d'administrateur sont actifs. Vous pouvez utiliser une classe Installer .NET qui pourra être instanciée par Windows Installer (si vous faites appel au déploiement .msi) ou par l'utilitaire système InstallUtil.exe dans le cas contraire. Pour plus d'informations sur l'utilisation des programmes d'installation du journal d'événements, reportez-vous au module 10, « Création de pages Web et de contrôles ASP.NET sécurisés ».

Si vous êtes dans l'impossibilité de créer des sources d'événement lors de l'installation, vous devez ajouter des autorisations à la clé de Registre suivante en accordant l'accès au compte de processus ASP.NET ou à tout compte représenté si votre application utilise l'emprunt d'identité.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Eventlog 

Les comptes doivent au minimum posséder les autorisations suivantes :

  • requête valeur de clé ;

  • affectation valeur de clé ;

  • création sous-clé ;

  • énumération des sous-clés ;

  • notification ;

  • lecture ;

Accès aux fichiers

Pour chaque fichier auquel votre application doit accéder, il doit correspondre une entrée de contrôle d'accès (ACE) dans la liste de contrôle d'accès, accordant au compte de processus ASP.NET ou à l'identité représentée un accès en lecture (au minimum) à ce fichier. En principe, les listes de contrôle d'accès sont configurées au niveau du répertoire ; les fichiers héritent des paramètres qui y sont définis.

En plus des autorisations NTFS qui restreignent l'accès aux fichiers et aux répertoires, vous pouvez recourir aux niveaux de confiance ASP.NET pour limiter l'accès des applications et des services Web à certaines zones du système de fichiers. Les applications Web à niveau de confiance moyenne, par exemple, peuvent uniquement accéder aux fichiers situés dans l'arborescence de leur propre répertoire virtuel.

Pour plus d'informations sur la stratégie de sécurité d'accès au code, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ».

Listes de contrôle d'accès et autorisations

Le compte de processus ASP.NET (ainsi que toutes les identités représentées, pour certains répertoires, si votre application utilise l'emprunt d'identité) nécessite les autorisations NTFS décrites ci-dessous. Les autorisations énumérées dans le tableau 19.3 doivent être définies en plus de toutes les autorisations éventuellement requises par vos applications pour accéder aux ressources de système de fichiers dont elles ont spécifiquement besoin.

Tableau 19.3 : Autorisations NTFS requises pour les comptes de processus ASP.NET

Répertoire

Autorisations requises

Fichiers ASP.NET temporaires%Files%windir%\Microsoft.NET\Framework\{version}Temporary ASP.NET Files

Compte de processus et identités représentées :
Contrôle total

Répertoire temporaire(%temp%)

Compte de processus :
Contrôle total

Répertoire .NET Framework%windir%\Microsoft.NET\Framework\{version}

Compte de processus et identités représentées :
Lecture et Exécution
Affichage du contenu du dossier
Lecture

Répertoire de configuration .NET Framework%windir%\Microsoft.NET\Framework\{version}\CONFIG

Compte de processus et identités représentées :
Lecture et Exécution
Affichage du contenu du dossier
Lecture

Racine du site Web
C:\inetpub\wwwroot
ou le chemin vers lequel pointe le site Web par défaut

Compte de processus :
Lecture

Répertoire racine système
%windir%\system32

Compte de processus :
Lecture

Répertoire Global Assembly Cache
%windir%\assembly

Compte de processus et identités représentées :
Lecture

Répertoire de contenu
C:\inetpub\wwwroot\YourWebApp

Compte de processus :
Lecture et Exécution
Affichage du contenu du dossier
Lecture
Remarque : dans .NET Framework version 1.0, tous les répertoires parent jusqu'au répertoire racine du système de fichiers, doivent également posséder ces autorisations. Parmi ces répertoires parent, citons :
C:\
C:\inetpub\
C:\inetpub\wwwroot\

Registre

Pour chaque clé de Registre à laquelle votre application doit accéder, il doit correspondre une entrée de contrôle d'accès (ACE) dans la liste de contrôle d'accès, accordant un accès en lecture (au minimum) au compte de processus ASP.NET ou à l'identité représentée.

Accès aux données

Pour accéder à une base de données distante en utilisant l'authentification Windows à partir de votre application ASP.NET, plusieurs possibilités s'offrent à vous :

  • Utiliser le compte de processus ASP.NET par défaut. Utilisez le compte de processus ASP.NET par défaut en créant un compte miroir avec le même nom d'utilisateur et le même mot de passe sur le serveur de base de données. Sur Windows 2000, le compte de processus par défaut est ASPNET. Sur Windows Server 2003, le compte de processus par défaut est Service réseau.

    L'inconvénient d'utiliser les comptes locaux réside dans le fait que si l'utilisateur parvient à vider la base de données SAM (ce qui nécessite des privilèges d'administration), il peut accéder aux informations d'authentification. Le principal avantage tient du fait qu'il est possible de limiter la portée des comptes locaux à certains serveurs, ce qui est difficile à réaliser avec des comptes de domaine.

  • Utiliser un compte de domaine configuré sur le principe du « moindre privilège » pour exécuter ASP.NET. Cette approche simplifie l'administration et évite d'avoir à synchroniser les mots de passe des comptes miroir. Elle ne fonctionnera pas si le serveur Web et le serveur de base de données se trouvent sur des domaines séparés non autorisés à approuver, ou encore si un pare-feu sépare les deux serveurs et bloque les ports requis pour l'authentification Windows.

  • Emprunter l'identité du compte Web anonyme.
    Lorsque vous utilisez l'authentification par formulaire ou passeport, vous pouvez emprunter l'identité du compte Web anonyme (IUSR_MACHINE par défaut) et créer un compte miroir sur le serveur de base de données. Cette approche est utile lorsque plusieurs applications Web sont hébergées sur le même serveur Web. Vous pouvez utiliser IIS pour configurer un compte anonyme différent dans le répertoire virtuel de chaque application.

    Sur Windows Server 2003, il est possible d'exécuter plusieurs applications dans des processus de traitement séparés, en utilisant les pools d'applications d'IIS 6.0 et en configurant une identité distincte pour chaque application.

Configuration de l'accès aux données pour votre application ASP.NET

Quelle que soit l'approche choisie, vous devez limiter les droits de l'application dans la base de données. Pour ce faire, créez un compte de connexion SQL Server pour le compte, accordez-lui l'accès à la base de données en question et limitez ses autorisations de sorte qu'il puisse uniquement accéder aux objets de base de données strictement nécessaires. Dans l'idéal, vous devez limiter les autorisations du compte de connexion aux seules procédures stockées que l'application ou le service Web utilise.

La procédure ci-dessous part du principe que vous utilisez un compte local miroir, mais vous pouvez également l'appliquer à un compte de domaine pour restreindre les autorisations du compte dans la base de données.

  • Pour configurer l'accès aux données de votre application ASP.NET :

    1. Utilisez l'outil Gestion de l'ordinateur pour remplacer le mot de passe du compte ASPNET local sur le serveur Web par un mot de passe sûr connu.
      Cette opération est nécessaire afin de pouvoir créer un compte miroir sur le serveur de base de données.

    2. Modifiez l'attribut password de l'élément <processModel> dans Machine.config pour que le processus de traitement ASP.NET continue de s'exécuter avec le compte ASPNET. Utilisez Aspnet_setreg.exe pour stocker les informations d'authentification sous forme cryptée dans le Registre.

    3. Créez un compte local sur le serveur de base de données en gardant le même nom (ASPNET) et le même mot de passe sûr.

    4. Créez un groupe Windows local sur le serveur de base de données, ASPNETWebApp par exemple, et ajoutez-lui le compte ASPNET local.

    5. Accordez au groupe Windows l'accès à SQL Server en créant un nouveau compte de connexion, comme suit :

      sp_grantlogin 'MACHINE\ASPNETWebApp'

      Remarque : remplacez MACHINE par le nom de votre serveur de base de données.

    6. Accordez au compte de connexion SQL l'accès à la base de données. Le code T-SQL suivant crée un utilisateur de base de données appelé WebAppUser, auquel le compte de connexion est associé.

      USE YourDatabase
      GO
      sp_grantdbaccess 'MACHINE\ASPNETWebApp', 'WebAppUser'
      
    7. Créez un rôle de base de données défini par l'utilisateur.

      USE YourDatabase
      GO
      sp_addrole 'WebAppUserRole'
      
    8. Ajoutez l'utilisateur de base de données au nouveau rôle de base de données.

      USE YourDatabase
      GO
      sp_addrolemember 'WebAppUserRole', 'WebAppUser'
      
    9. Dans la base de données, configurez les autorisations du rôle de base de données. Dans l'idéal, vous devez uniquement accorder les autorisations d'exécution sur les procédures stockées que l'application utilise pour interroger la base de données et interdire tout accès direct aux tables.

      grant execute on sprocname to WebAppUserRole

Partages UNC

Votre application ASP.NET peut recourir aux partages UNC dans deux principaux cas :

  • Accès aux fichiers de partages UNC
    Votre application doit par exemple accéder à un fichier distant tel que \\remoteserver\share\somefile.dat.

  • Hébergement d'applications sur des partages UNC
    Le répertoire virtuel IIS de votre application est mappé sur un partage distant, par exemple \\remoteserver\appname. Dans ce scénario, les requêtes HTTP sont traitées par le serveur Web, mais les pages, les ressources et les assemblys privés de l'application se trouvent sur le partage distant.

Accès aux fichiers de partages UNC

Si votre application accède aux fichiers d'un partage UNC, le compte de processus ASP.NET (ou toute identité représentée) doit posséder les droits d'accès appropriés définis dans la liste de contrôle d'accès sur le partage et sur le répertoire ou le fichier sous-jacent.

Si vous utilisez le compte de processus ASPNET local, qui ne possède pas d'identité réseau, vous devez créer un compte miroir sur le serveur distant en reprenant le même nom d'utilisateur et le même mot de passe, ou utiliser un compte de domaine le moins privilégié disposant d'un accès aux deux serveurs. Sur Windows Server 2003, le compte Service réseau servant à exécuter les applications Web ASP.NET peut être authentifié sur le réseau ; il vous suffit donc d'accorder les droits d'accès au compte ordinateur.

Hébergement d'applications sur des partages UNC

Vous pouvez utiliser IIS pour configurer un répertoire virtuel afin qu'il pointe vers un partage UNC situé sur un autre ordinateur, par exemple \\remoteserver\appname. IIS vous demande alors de fournir les informations d'authentification du compte, qu'il utilise pour établir une connexion vers l'ordinateur distant.

Remarque : les informations d'authentification du compte sont stockées sous forme cryptée dans la métabase IIS, mais sont disponibles par l'intermédiaire d'une API. Vous devez veiller à utiliser un compte doté des privilèges minimum. Pour plus d'informations, consultez l'article 280383 de la Base de connaissances Microsoft, « IIS Security Recommendations When You Use a UNC Share and Username and Password Credentials ».

Si votre application réside sur un partage UNC, ASP.NET emprunte l'identité du jeton UNC fourni par IIS (créé à partir des informations d'authentification de compte que vous lui avez spécifiées) pour accéder au partage, à moins que vous ayez activé l'emprunt d'identité en indiquant une identité prédéfinie, comme dans la configuration suivante :

<identity impersonate="true"
  userName="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,userName"
  password="registry:HKLM\SOFTWARE\YourApp\identity\ASPNET_SETREG,password"/>

Si l'emprunt d'identité d'un compte prédéfini est spécifié dans les attributs userName et password, ASP.NET accède au partage en utilisant ce compte prédéfini plutôt que le jeton UNC d'IIS. Tous les accès aux ressources réalisés par votre application passent également par le compte prédéfini.

Remarque : dans l'exemple ci-dessus, Aspnet_setreg.exe a été utilisé pour stocker les informations d'authentification sous forme cryptée dans le Registre.

Si vous activez l'emprunt d'identité de l'appelant initial (l'identité d'authentification IIS) en appliquant la configuration ci-dessous, ASP.NET continue d'utiliser le jeton UNC pour accéder aux fichiers de votre application sur le partage, alors que tous les accès aux ressources réalisés par votre application utilisent le jeton représenté.

<identity impersonate="true" />

Remarque : le compte utilisé pour le partage UNC doit également pouvoir lire Machine.config.

Considérations relatives à la sécurité d'accès au code

Les applications situées sur un partage UNC bénéficient des autorisations intranet définies par la stratégie de sécurité d'accès au code. L'ensemble d'autorisations intranet n'inclut pas l'autorisation AspNetHostingPermission, nécessaire à l'exécution des applications Web ASP.NET. Vous devez donc modifier explicitement la stratégie pour que votre application puisse s'exécuter.

Deux possibilités s'offrent à vous :

  • Accorder une confiance totale au partage UNC hébergeant votre application.
    C'est l'option la plus simple à gérer. Si vous utilisez .NET Framework version 1.0, c'est la seule possibilité car les applications Web ASP.NET version 1.0 requièrent une confiance totale.

  • Configurer la stratégie d'accès au code pour accorder l'autorisation AspNetHostingPermission à votre code et toutes les autorisations nécessaires en fonction des types de ressources auxquelles il accède et des opérations qu'il réalise.
    Étant donné qu'ASP.NET crée le code et compile les classes de page de manière dynamique, vous devez utiliser un groupe de codes pour le partage UNC et le répertoire des fichiers ASP.NET temporaires au moment de configurer la stratégie. Le répertoire temporaire par défaut est \WINNT\Microsoft.NET\Framework\{version}\Temporary ASP.NET Files, mais vous pouvez modifier cet emplacement pour chaque application grâce à l'attribut tempDirectory de l'élément <compilation>.

    Pour plus d'informations sur la stratégie de sécurité d'accès au code et le code privilégié en sandbox, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ».

    Remarque : au moment de configurer la stratégie, accordez la confiance au partage (en spécifiant un emplacement de fichier) plutôt qu'à la zone. Vous obtenez ainsi une granularité plus fine puisque cela n'affecte pas toutes les applications d'une zone donnée.

Ressources COM/DCOM

Votre application utilise le compte de processus ou l'identité représentée pour appeler les ressources basées sur COM (ndash), telles que les composants de service. Les niveaux d'authentification et d'emprunt d'identité côté client sont configurés à l'aide des attributs de niveau comAuthenticationLevel et comImpersonation dans l'élément <processModel> du fichier Machine.config.

Pour obtenir plus d'informations et de recommandations, reportez-vous à la section « Enterprise Services Considerations » du module 17, « Sécurisation de votre serveur d'applications ».

Considérations relatives au déni de service

ASP.NET inclut les fonctionnalités suivantes pour contrer les attaques par déni de service visant vos applications ASP.NET :

  • Les requêtes POST sont limitées par défaut à 4 méga-octets (Mo).

  • Avant de placer les requêtes en file d'attente, ASP.NET vérifie que les clients sont toujours connectés. Cette mesure permet d'éviter le risque qu'un pirate envoie plusieurs requêtes qu'il déconnecte aussitôt.

  • L'exécution des requêtes expire au bout d'un délai configurable.

<httpRuntime>

Les valeurs de configuration sont définies dans l'élément <httpRuntime> de Machine.config. L'exemple de code ci-dessous montre les paramètres par défaut d'un fichier Machine.config version 1.1 :

<httpRuntime executionTimeout="90" 
             maxRequestLength="4096" 
             useFullyQualifiedRedirectUrl="false" 
             minFreeThreads="8" 
             minLocalRequestFreeThreads="4" 
             appRequestQueueLimit="100" 
             enableVersionHeader="true"/>

Vous pouvez réduire la valeur de l'attribut maxRequestLength pour empêcher les utilisateurs de télécharger des fichiers trop volumineux. La valeur maximale autorisée est de 4 Mo. Lors du concours Open Hack, l'attribut maxRequestLength a été limité à 0,5 Mo comme l'illustre l'exemple suivant :

<system.web>
   <!-- Taille d'envoi max de 1/2 Mo -->
   <httpRuntime maxRequestLength="512"/>
</system.web>

Remarque : ASP.NET n'inclut pas de fonctionnalités destinées à contrer les attaques au niveau paquet. Pour ce faire, vous devez renforcer la pile TCP/IP. Pour plus d'informations sur la configuration de la pile TCP/IP, reportez-vous à la section « Procédure : renforcement de la pile TCP » dans la section des procédures de ce guide.

Considérations relatives aux batteries de serveurs

Si votre application Web ASP.NET s'exécute sur une batterie de serveurs, il est possible que des requêtes successives d'un même client ne soient pas traitées par le même serveur Web. Cela a des répercussions sur :

  • l'état de session ;

  • le cryptage et la vérification ;

  • DPAPI.

État de session

Pour éviter l'affinité de serveur, maintenez l'état de session ASP.NET hors processus dans la base de données d'état SQL Server ASP.NET ou dans le service d'état hors processus qui s'exécute sur un ordinateur distant. Pour plus d'informations sur la sécurisation de l'état de session dans un magasin d'état distant, reportez-vous à la section « État de session » abordée précédemment dans ce module.

Cryptage et la vérification

Les clés servant à crypter et à vérifier les cookies d'authentification par formulaire doivent être identiques sur tous les serveurs de la batterie de serveurs. Vous devez remplacer les paramètres AutoGenerate de l'élément <machineKey> par des valeurs de clé communes.

Pour plus d'informations sur la génération et la configuration des clés, reportez-vous à l'article 312906 de la Base de connaissances Microsoft, « How To: Create Keys by Using Visual C# .NET for Use in Forms Authentication ».

DPAPI

Pour crypter les données, les développeurs ont parfois recours à DPAPI. Si vous utilisez DPAPI avec la clé ordinateur pour stocker les secrets, la chaîne cryptée est spécifique à l'ordinateur ; vous ne pouvez pas copier les données cryptées d'un ordinateur à l'autre au sein de la batterie de serveurs ou du cluster.

Si vous utilisez DPAPI avec une clé utilisateur, vous pouvez décrypter les données sur n'importe quel ordinateur en utilisant un profil utilisateur itinérant. Toutefois, cela n'est pas conseillé car les données peuvent alors être décryptées par n'importe quel ordinateur du réseau capable d'exécuter du code à partir du compte ayant crypté les données.

DPAPI convient parfaitement au stockage des secrets de configuration, comme les chaînes de connexion de base de données situées sur le serveur Web. Lorsque les données cryptées sont stockées sur un serveur distant, dans une base de données par exemple, vous devez utiliser d'autres techniques de cryptage. Pour plus d'informations sur le stockage de données cryptées dans la base de données, reportez-vous au module 14, « Création d'un accès sécurisé aux données ».

Instantané d'une application ASP.NET sécurisée

L'instantané ci-dessous contient les attributs d'une application ASP.NET sécurisée. Vous pouvez les comparer rapidement et facilement avec votre propre configuration.

Tableau 19.4 : Instantané d'une application ASP.NET sécurisée

Composant

Caractéristiques

Identité de processus

Le processus de traitement ASP.NET s'exécute en tant qu'ASPNET :

<processModel username="machine"
password="AutoGenerate" />

Le compte personnalisé (s'il est utilisé) est le moins privilégié.
Les paramètres d'authentification du compte personnalisé sont cryptés dans le Registre :

<processModel 
	userName="registry:HKLM\SOFTWARE\YourApp\
process\ASPNET_SETREG,userName"  
	password="registry:HKLM\SOFTWARE\YourApp\
process\ASPNET_SETREG,password"/>

Emprunt d'identité

Les identités représentées sont cryptées dans le Registre :

<identity impersonate="true"
	userName="registry:HKLM\SOFTWARE\YourApp\
identity\ASPNET_SETREG,userName"
	password="registry:HKLM\SOFTWARE\YourApp\
identity\ASPNET_SETREG,password"/>

Authentification

Le site Web est partitionné en deux : l'accès public et l'accès restreint.
La configuration de l'authentification par formulaire est sûre :

<forms loginUrl="Restricted\login.aspx" 
	protection="All"
	requireSSL="true"      
	timeout="10"      
	name="AppNameCookie"
	path="/FormsAuth"
	slidingExpiration="true" />

Le cookie d'authentification est crypté et son intégrité est vérifiée.
Le cookie d'authentification requiert SSL.
Le paramètre d'expiration décalée est défini sur false, si SSL n'est pas utilisé.
La durée de vie de la session est limité.
Les noms de cookie et les chemins sont uniques.
L'élément <credentials> n'est pas utilisé.

Autorisation

Des listes de contrôle d'accès sont configurées pour les ressources ASP.NET.
Les éléments <authorization> sont définis.

État de session

Le service d'état ASP.NET est désactivé s'il n'est pas nécessaire.

   
<sessionState  mode="Off " />  

Le canal de communication vers le magasin d'état distant est crypté si nécessaire.
L'authentification Windows est utilisée pour la connexion à la base de données ASPState.
L'application possède des droits d'accès limités dans la base de données ASPState.
Les paramètres de connexion (sqlConnectionString
et stateConnectionString) sont cryptés dans le Registre.
Le service d'état ASP.NET est configuré pour utiliser un port différent du port par défaut.

État d'affichage

Le code d'authentification de message de l'état d'affichage est activé dans l'élément <pages> du fichier Machine.config.

Clé ordinateur

L'attribut validation est défini sur SHA1.
Les clés de chaque application exécutée sur le serveur Web sont uniques.
L'état d'affichage et l'authentification par formulaire sont protégés :

  
<machineKey validationKey="AutoGenerate,IsolateApps"            
	decryptionKey="AutoGenerate,IsolateApps"           
	validation="SHA1"/>

Ressources protégées

Les ressources protégées sont mappées sur System.Web.HttpForbiddenHandler.

Débogage

Les versions debug sont désactivées :

 
<compilation debug="false" . . .

Traçage

Le traçage est désactivé.

 
<trace enabled='false' localOnly='true . . .

Gestion des exceptions

Les erreurs personnalisées sont activées.
La page de redirection par défaut est utilisée :

<customErrors mode="On"
         defaultRedirect="YourErrorPage.htm" /> 

Accès distant

L'accès distant est désactivé sur les serveurs Web directement connectés à Internet :

<httpHandlers>
 <add verb="*" path="*.soap"
  	type="System.Web.HttpForbiddenHandler"/>
<add verb="*" path="*.rem"
	type="System.Web.HttpForbiddenHandler"/>
. . .	
</httpHandlers>

Services Web

Les services Web sont désactivés s'ils ne sont pas nécessaires :

<httpHandlers>
    <add verb="*" path="*.asmx"
             type="System.Web.HttpForbiddenHandler"/>
                   . . .
</httpHandlers>

Les protocoles inutiles sont désactivés :

<webServices>
	<protocols>      
		<!-- <add name="HttpPost"/> -->
		<!-- <add name="HttpGet"/> -->.... 

Le protocole Documentation est désactivé pour éviter la génération automatique de fichiers WSDL :

<webServices>
 	 <protocols>
 	 		<!--<add name="Documentation"/>-->
. . .  

Répertoire Bin

Le répertoire bin est sécurisé.
( Le répertoire bin ne contient pas d'autorisations Lecture, Écriture et Exploration de répertoire.
Les autorisations Exécution sont définies sur Aucune.)
Les paramètres d'authentification sont supprimés du répertoire bin.

Résumé

Ce module vous a montré comment sécuriser une application ou un service Web ASP.NET en définissant les paramètres de configuration relatifs aux comptes, services, protocoles, fichiers et répertoires, et en modifiant les données de configuration stockées dans les fichiers Machine.config et Web.config. Ce module vous a également montré comment sécuriser les différents domaines fonctionnels sur lesquels les applications et les services Web ASP.NET reposent, notamment l'authentification, l'autorisation, l'état de session et l'accès aux données.

Pour obtenir la liste de contrôle associée à ce module, reportez-vous à la section « Liste de contrôle : sécurisation d'ASP.NET » dans la section des listes de contrôle de ce guide.

Ressources supplémentaires

Pour plus d'informations, consultez les ressources et les articles ci-dessous :

Afficher:
© 2014 Microsoft