Sécurisation de l'appartenance (membership)
Mise à jour : novembre 2007
L'appartenance d'ASP.NET fournit des fonctionnalités de gestion et d'authentification des utilisateurs et est utilisée le plus fréquemment avec l'authentification par formulaire et les contrôles d'authentification, par exemple les contrôles Login, LoginView, LoginStatus, LoginName, PasswordRecovery et CreateUserWizard. Cette rubrique explique comment optimiser la sécurité de la fonctionnalité d'appartenance en appliquant les méthodes conseillées pour configurer un site Web et coder avec les classes d'appartenance.
Bien que l'application de ces méthodes conseillées puisse améliorer la sécurité de votre application, il est également important de mettre à jour en permanence votre serveur d'application à l'aide des derniers correctifs de sécurité pour Microsoft Windows et les services IIS (Internet Information Services), ainsi que tous les correctifs pour Microsoft SQL Server ou d'autres sources de données d'appartenance.
Pour plus d'informations sur les méthodes conseillées relatives à l'écriture d'un code sécurisé et la sécurisation des applications, consultez le manuel « Writing Secure Code » de Michael Howard et David LeBlanc et l'aide fournie par Microsoft Patterns and Practices (https://www.microsoft.com/resources/practices/default.mspx).
Configuration d'appartenance sécurisée
La fonction d'appartenance est activée par défaut pour les applications ASP.NET et ne peut pas être désactivée. Les paramètres de configuration par défaut ont les valeurs les plus sécurisées. Pour plus d'informations sur les paramètres de configuration d'appartenance et leurs valeurs par défaut, consultez membership, élément (Schéma des paramètres ASP.NET). Vous devez affecter la valeur true à l'attribut requiresQuestionAndAnswer, notamment lorsque l'attribut enablePasswordReset ou enablePasswordRetrieval a également la valeur true.
Sécurisation de valeurs de configuration
Lorsque vous stockez des informations sensibles dans un fichier de configuration pour une application, vous devez chiffrer les valeurs sensibles à l'aide de la configuration protégée. Les informations qui sont particulièrement sensibles incluent 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.
Clés de chiffrement sécurisées et hachage
Il est vivement recommandé de chiffrer les mots de passe utilisateur dans la source de données d'appartenance à l'aide d'un attribut passwordFormat dont la valeur est Hashed ou Encrypted, Hashed désignant le format le plus sécurisé. Les valeurs de clés de chiffrement pour l'algorithme de chiffrement spécifié sont stockées dans l'élément de configuration machineKey. Pour renforcer le chiffrement, spécifiez une clé de chiffrement qui est une valeur générée aléatoirement de la longueur appropriée pour l'algorithme de chiffrement sélectionné.
Sur un serveur qui héberge plusieurs applications, il est recommandé de définir des clés de chiffrement uniques pour chaque application. Une solution moins sécurisée consiste à définir une clé de chiffrement unique et à définir l'option IsolateApps à l'aide de la clé.
Vous pouvez paramétrer la configuration d'ordinateur sur un serveur hôte de sorte que les applications ne puissent pas substituer les paramètres de configuration. Cela inclut le fait d'empêcher que les clés de chiffrement soient redéfinies dans le fichier Web.config d'une application.
Sécurisation des connexions à une source de données d'appartenance
Chaînes de connexion
Pour sécuriser la connexion à votre serveur de base de données, vous devez chiffrer les informations de la chaîne de connexion dans la configuration à l'aide de la configuration protégée. Pour plus d'informations, consultez Chiffrement des informations de configuration à l'aide de la configuration protégée.
Connexion à SQL Server à l'aide de la sécurité intégrée
Vous devez vous connecter aux ordinateurs qui exécutent SQL Server à l'aide de la sécurité intégrée pour éviter que votre chaîne de connexion soit compromise et que votre ID d'utilisateur et votre mot de passe soient accessibles. Lorsque vous spécifiez une connexion qui utilise la sécurité intégrée pour vous connecter à un ordinateur qui exécute SQL Server, la fonctionnalité d'appartenance rétablit l'identité du processus. Vous devez vérifier que l'identité du processus qui exécute ASP.NET (par exemple, le pool d'applications) correspond au compte de processus par défaut ou à un compte d'utilisateur restreint. Pour plus d'informations, consultez Emprunt d'identité ASP.NET.
Autorisations de la base de données SQL Server
La base de données SQL Server qui est utilisée pour stocker les informations d'appartenance des utilisateurs inclut des rôles et des vues de base de données qui vous permettent de limiter l'accès des utilisateurs à la visibilité et aux fonctions requises. Vous devez assigner les privilèges minimums nécessaires à un ID d'utilisateur qui se connecte à la base de données d'appartenance SQL Server. Pour plus d'informations, consultez Rôles et vues dans la base de données des services d'application pour SQL Server.
Identité du processus de traitement SQL Server Express
SQL Server Express 2005 inclut un nouveau mode de fonctionnement qui permet de démarrer un processus de traitement qui s'exécute en tant qu'identité de l'utilisateur qui se connecte. Cette fonction est appelée mode « passage comme utilisateur ». Bien que ce mode de fonctionnement convienne au développement bureautique lors de l'utilisation des services IIS, le démarrage de processus de traitement n'est pas adapté aux serveurs Web qui hébergent plusieurs codes base de client non fiables. Les serveurs d'hébergement partagés qui contiennent des applications qui ne se font pas mutuellement confiance doivent désactiver explicitement la fonction « passage comme utilisateur ». Cette fonctionnalité peut être désactivée en se connectant à l'instance SQL Express (par exemple, osql –E –S .\sqlexpress) et en soumettant la commande Transact-SQL suivante.
EXEC sp_configure 'show advanced option', '1'
GO
RECONFIGURE WITH OVERRIDE
GO
EXEC sp_configure 'user instances enabled', 0
GO
RECONFIGURE WITH OVERRIDE
GO
Pages Web sécurisées qui utilisent l'appartenance
Les pages d'application qui utilisent des données sensibles, par exemple les pages d'ouverture de session, doivent être sécurisées à l'aide de mécanismes de sécurité Web standard. Ceux-ci incluent des mesures telles que l'utilisation du protocole SSL (SSL, Secure Socket Layer) et la nécessité pour les utilisateurs d'ouvrir une session pour exécuter des opérations sensibles comme la mise à jour d'informations utilisateur ou la suppression d'utilisateurs.
En outre, les pages ne doivent pas exposer de données de fonctionnalité sensibles (telles que des mots de passe et, dans certains cas, des noms d'utilisateurs) en texte clair. Assurez-vous que les pages qui affichent de telles informations utilisent le protocole SSL et ne sont accessibles qu'aux utilisateurs authentifiés. De même, évitez de stocker des données de fonctionnalité sensibles dans les cookies ou de les envoyer via des connexions non fiables.
Sécurisation contre les attaques par déni de service
Les méthodes qui exécutent des mises à jour ou de grandes opérations de recherche peuvent réduire la réactivité de votre source de données d'appartenance si elle est appelée en même temps par plusieurs clients. Pour éviter d'être exposé à une attaque par déni de service, limitez l'accès aux pages ASP.NET qui utilisent des méthodes qui exécutent des recherches ou des mises à jour de base de données aux utilisateurs administratifs et exposez uniquement les pages ASP.NET qui fournissent une gestion de la validation et du mot de passe pour une utilisation générale.
Messages d'erreur et événements
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, etc. pour éviter toute attaque par déni de service indirecte.
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.
Fournisseurs d'appartenances personnalisés
Lors de la création d'un fournisseur d'appartenances personnalisé, vérifiez que vous appliquez les méthodes conseillées en matière de sécurité pour éviter des attaques telles que des attaques d'injection SQL lors de l'utilisation d'une base de données. Lorsque vous utilisez un fournisseur d'appartenances personnalisé, assurez-vous que celui-ci applique les méthodes conseillées en termes de sécurité.
Utilisation de caractères dépendants de la culture
Lors de l'utilisation du fournisseur d'appartenances SQL Server ou d'un fournisseur d'appartenances personnalisé, votre source de données peut être configurée pour stocker des données d'appartenance sous un format dépendant de la culture. Toutefois, ASP.NET évalue les noms d'utilisateurs de l'élément de configuration authorization et les noms d'utilisateurs du magasin de données d'appartenance comme indifférents de la culture. Par conséquent, un utilisateur non autorisé peut recevoir l'autorisation car, lorsque le nom d'utilisateur est traité comme indifférent de la culture, il s'agit du même nom que celui d'un utilisateur autorisé.
Pour éviter d'accorder l'accès à des utilisateurs non autorisés, assurez-vous que les noms d'utilisateurs sont uniques lorsqu'ils sont évalués comme étant indifférents de la culture. Vous pouvez également spécifier uniquement des noms de rôles pour l'autorisation à l'aide de l'élément de configuration authorization, puis vous assurer que ces noms de rôles sont uniques lorsqu'ils sont évalués comme étant indifférents de la culture. La spécification de l'autorisation à l'aide de noms de rôles est souvent préférée, car la création et la gestion de rôles peuvent être restreintes en tant que fonction administrative.