Sécurisation de la configuration ASP.NET

Article
10/22/2014

Mise à jour : novembre 2007

La configuration ASP.NET fournit des fonctionnalités visant à configurer tout un serveur, une application ASP.NET ou des pages individuelles dans les sous-répertoires d'application. Vous pouvez configurer des fonctionnalités comme les modes d'authentification, la mise en cache de pages, les options du compilateur, les erreurs personnalisées, les options de débogage et de traçage, et bien plus encore. Cette rubrique explique comment optimiser la sécurité des fonctionnalités de configuration à l'aide de méthodes conseillées lors de la configuration d'applications ASP.NET locales ou distantes. Pour plus d'informations sur la sécurisation d'autres fonctionnalités ASP.NET, consultez les informations présentées dans la section Voir aussi.

Même si l'application des méthodes conseillées en matière de codage et de configuration peut vous aider à renforcer la sécurité de votre application, il est important de tenir votre serveur d'applications à jour avec les dernières mises à jour de sécurité de Microsoft Windows et des services Microsoft IIS (Internet Information Services), ainsi qu'avec les mises à jour de Microsoft SQL Server ou d'autres sources de données d'appartenance.

Pour plus d'informations sur les méthodes conseillées en matière d'écriture de code sécurisé et de sécurisation des applications, consultez le manuel « Writing Secure Code », de Michael Howard et David LeBlanc, et reportez-vous à l'aide fournie par le site Web Microsoft Patterns and Practices.

Remarque importante :
Le système de configuration ASP.NET configure uniquement les ressources et fonctionnalités ASP.NET. Utilisez les fonctionnalités de configuration d'IIS pour configurer des ressources non-ASP.NET. Pour plus d'informations sur la configuration d'IIS, consultez Working with the Metabase (IIS 6.0) et IIS Metabase Property Reference.

Sécurité des fichiers de configuration

Le tableau suivant répertorie les listes de contrôle d'accès (ACL) définies par défaut dans le fichier Machine.config et le fichier Web.config racine, tous deux situés dans le répertoire %SystemRoot%\Microsoft.NET\Framework\version\CONFIG. Ces listes de contrôle d'accès sont également définies sur le répertoire lui-même, mais elles incluent des autorisations Modifier pour le groupe Utilisateurs avec pouvoir. Le répertoire est en lecture seule.

Compte Windows	Autorisations
Administrateurs	Contrôle total
Compte d'ordinateur ASP.NET (<serveur>\ASPNET)	Lecture et exécution
IIS_WPG (<serveur>\IIS_WPG)	Lecture et exécution
SERVICE LOCAL	Lecture et exécution
SERVICE RÉSEAU	Lecture et exécution
Utilisateurs avec pouvoir (<serveur>\Power Users)	Modifier
SYSTEM	Contrôle total
Utilisateurs (<serveur>\Users)	Lecture et exécution

Le tableau suivant répertorie les listes de contrôle d'accès qui doivent être définies sur les fichiers Web.config et sur tous les fichiers répertoriés dans les attributs configSource.

Compte Windows	Autorisations
Administrateurs	Contrôle total
IIS_WPG (<serveur>\IIS_WPG)	Lecture et exécution
INTERACTIF	Lire
Compte Invité Internet (<serveur>\IUSR_<serveur>)	Lire
RÉSEAU	Lire
SERVICE RÉSEAU	Lire
SYSTEM	Contrôle total
Utilisateurs (<serveur>\Users)	Lecture et exécution
Compte Outil Administration de site Web ASP.NET	Spécial

Le système de configuration ASP.NET respecte les listes de contrôles d'accès définies sur les fichiers de configuration, indépendamment de la façon dont les paramètres de configuration sont modifiés. Pour plus d'informations, consultez Modification des fichiers de configuration ASP.NET.

Sécurisation de valeurs de configuration

Lorsque vous stockez des informations sensibles dans un fichier de configuration pour une application, il est conseillé de chiffrer les valeurs sensibles à l'aide de la configuration protégée. Parmi les informations particulièrement sensibles, citons les clés de chiffrement stockées dans l'élément de configuration machineKey et les chaînes de connexion à une source de données stockées dans l'élément de configuration connectionStrings. Pour plus d'informations, consultez Chiffrement des informations de configuration à l'aide de la configuration protégée.

Protection des conteneurs des clés de chiffrement de la configuration

Un aspect critique de l'utilisation d'une clé de chiffrement est la protection du fichier, appelé également conteneur, dans lequel la clé est stockée. Un élément important à prendre en considération est le niveau de protection associé au conteneur. Notez que le conteneur est stocké dans un fichier du système d'exploitation normal et que l'accès à la clé de chiffrement est contrôlé par les listes de contrôle d'accès (ACL) du fichier. Les listes ACL peuvent être héritées du dossier dans lequel le fichier est créé. Les conteneurs de clé avec une portée d'ordinateur local (useMachineContainer "true") sont stockés dans un dossier masqué sous %ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys.

Par défaut, l'utilisateur qui a créé le conteneur de clé dispose d'un accès complet à la clé. Les autres utilisateurs (y compris le groupe Administrateurs) peuvent ou non avoir accès au conteneur, selon les listes ACL configurées pour le conteneur. Il est possible d'octroyer l'accès au conteneur à d'autres utilisateurs à l'aide du commutateur –pa de l'outil ASP.NET IIS Registration (ASP.NET IIS Registration, outil (Aspnet_regiis.exe)). Les utilisateurs qui tentent d'effectuer un chiffrement ou un déchiffrement avec la clé spécifiée doivent posséder les autorisations requises pour accéder au conteneur de clé.

Dans certains cas, un utilisateur sans privilèges d'administration peut néanmoins créer une clé de chiffrement. Cela peut arriver si une application demande un chiffrement de la configuration et qu'il n'existe pas de clé. Notez que le conteneur est créé s'il n'existe pas et qu'une opération de chiffrement est exécutée.

Dans ce cas, le .NET Framework crée la clé et le conteneur associé requis avec les listes ACL de l'utilisateur actuel. Cela présente un problème potentiel, à savoir qu'un utilisateur doté de privilèges d'administration peut, dans ce cas, se voir refuser l'accès au conteneur de clé de chiffrement. L'administrateur peut récupérer l'accès à la clé en devenant propriétaire du fichier physique du dossier mentionné ci-dessus. Il est dès lors recommandé qu'un utilisateur doté de privilèges d'administration crée les clés nécessaires avant qu'elles soient utilisées, pour éviter de les créer au moment du chiffrement.

Sécurisation de la configuration dans un environnement d'hébergement partagé

Dans un environnement d'hébergement partagé, des utilisateurs malveillants peuvent arriver à modifier des paramètres de configuration par une modification directe des fichiers de configuration, par une modification via les API de configuration et via d'autres outils d'administration et de configuration. Vous pouvez empêcher la modification de la configuration de votre application en verrouillant les sections de configuration. Pour ce faire, ajoutez des éléments location au fichier Machine.config ou à tout fichier de configuration situé plus haut dans la hiérarchie que le fichier de configuration dont vous souhaitez limiter l'accès. L'élément location est utilisé pour empêcher des fichiers de configuration enfants de modifier des paramètres. Pour plus d'informations, consultez Comment : verrouiller des paramètres de configuration ASP.NET et Comment : configurer des répertoires spécifiques à l'aide des paramètres d'emplacement.

Configuration à distance

La configuration à distance est désactivée par défaut. Lorsqu'elle est activée, l'utilisateur est authentifié au niveau DCOM et seuls les administrateurs locaux sont autorisés à lire ou à écrire des données de configuration. Pour plus d'informations, consultez Modification des fichiers de configuration distants ASP.NET.

Fournisseurs de configuration personnalisés

Indépendamment du jeton de sécurité de l'utilisateur actuel, le code de gestionnaire de section personnalisé s'exécute à l'aide des informations d'identification du compte de processus d'hébergement. Pour les scénarios Web, il s'agit du compte <serveur>\ASPNET sous Windows 2000 et Windows XP, du compte SERVICE RÉSEAU sous Windows Server 2003, ou d'un compte d'utilisateur explicitement configuré. Pour les scénarios clients, il s'agit de l'identité du processus en cours d'exécution.

Le système de configuration définit des autorisations avant d'appeler un gestionnaire de section de configuration personnalisé et le .NET Framework ne considère pas l'appel comme étant digne de confiance. L'appel s'exécute avec l'autorisation de confiance de l'application. Le système de configuration ASP.NET fait confiance au répertoire %SystemRoot%\Microsoft.NET\Framework\version\CONFIG, mais pas aux répertoires situés en-dessous dans la hiérarchie.

Un gestionnaire de section de configuration personnalisé doit définir des attributs de demande de sécurité d'accès du code (CAS) afin d'obtenir des autorisations. Pour plus d'informations, consultez Sécurité d'accès du code ASP.NET ou Notions fondamentales de la sécurité d'accès du code.

Verrouillage d'un fichier de configuration

Seules plusieurs tentatives d'enregistrement d'un fichier de configuration ou d'ouverture d'un handle de fichier peuvent verrouiller un fichier de configuration. Un utilisateur malveillant peut tenter de verrouiller le fichier Machine.config ou le fichier Web.config racine, mais, pour ce faire, il doit disposer d'une confiance totale, laquelle est désactivée par défaut dans ASP.NET.

Utilisation de l'API de configuration pour la lecture de fichiers arbitraires

Les classes de l'API de configuration ne peuvent pas lire des répertoires qui ne font pas partie du domaine d'application ou des fichiers qui n'ont pas d'extension de nom de fichier .config.

Application des paramètres de métabase IIS à une demande ASP.NET

Lorsque IIS reçoit une demande pour une application ASP.NET, les paramètres de métabase IIS sont appliqués à l'application ASP.NET, quels que soient les paramètres de configuration ASP.NET pour cette application. Cette contrainte peut se traduire par l'inaccessibilité d'applications ASP.NET aux utilisateurs ou par des paramètres de sécurité moins restrictifs pour ces applications.

Si, par exemple, les paramètres de sécurité dans la métabase IIS sont configurés pour autoriser uniquement l'accès au site aux utilisateurs authentifiés alors que les paramètres de sécurité dans le fichier Web.config sont configurés pour autoriser l'accès anonyme au site, les utilisateurs anonymes ne pourront pas accéder au site. Pour remédier à cela, vous devez configurer l'application Web dans le Gestionnaire des services IIS pour autoriser des utilisateurs anonymes.

Pour plus d'informations sur la sécurisation des fonctionnalités IIS, consultez Security in IIS 6.0.

Messages d'erreur et événements

Les sections suivantes traitent de la façon de limiter les problèmes de sécurité potentiels exposés par des messages d'erreur et des événements inattendus.

Exceptions

Pour empêcher que des informations sensibles ne soient exposées à des sources non autorisées, configurez votre application soit pour ne pas afficher de messages d'erreur détaillés, soit pour afficher des messages d'erreur détaillés uniquement lorsque le client est le serveur Web lui-même. Pour plus d'informations, consultez customErrors, élément (Schéma des paramètres ASP.NET).

Journal des événements

Si votre serveur exécute Windows Server 2003, vous pouvez améliorer la sécurité de votre application en sécurisant le journal des événements et en définissant des paramètres concernant sa taille, sa conservation, et d'autres fonctionnalités pour éviter toute attaque par déni de service indirecte. Pour plus d'informations sur la configuration des journaux d'événements, recherchez « Observateur d'événements » dans le Centre d'aide et de support de Windows.

Contrôle d'état

Les tentatives d'ouverture de session réussies et non réussies sont enregistrées à l'aide de la fonctionnalité de contrôle d'état ASP.NET. Dans la configuration par défaut, cela signifie que les tentatives de session non réussies enregistrent le nom d'utilisateur et les autres informations de diagnostic dans le journal des événements de l'application. Vérifiez que l'accès au journal des événements est restreint pour préserver la confidentialité de ces informations.