Méthodes de sécurité de base pour les applications Web

Mise à jour : novembre 2007

La rubrique sur la création d'une application Web sécurisée est complète. La compréhension de la vulnérabilité en matière de sécurité n'est pas chose aisée. Vous devez également vous familiariser avec les fonctionnalités relatives à la sécurité de Windows, du .NET Framework et de ASP.NET. Enfin, il vous faudra comprendre comment utiliser ces fonctionnalités afin de contrer les différentes menaces.

Même si vous n'êtes pas expérimenté en matière de sécurité, il vous faut prendre des mesures de base afin de protéger votre application Web. La liste suivante fournit des instructions sur la sécurité minimale, qui s'appliquent à toutes les applications Web et que vous devez respecter :

• Recommandations générales en matière de sécurité des applications Web

• Exécution des applications avec les privilèges les plus faibles possible

• Connaissance des utilisateurs

• Protection contre les entrées d'utilisateur nuisibles

• Accès sécurisé aux bases de données

• Création de messages d'erreur sécurisés

• Conservation sécurisée des secrets

• Utilisation sécurisée des cookies

• Protection contre les menaces de déni de service

  Remarque :
  Pour obtenir une aide complète et détaillée sur la sécurité qui vous aidera à concevoir, développer, configurer et déployer des applications Web ASP.NET mieux sécurisées, consultez les modules de sécurité fournis sur le site Web Microsoft Patterns and Practices.

Recommandations générales en matière de sécurité des applications Web

Même la sécurité la plus élaborée peut échouer face à un utilisateur malveillant en mesure d'utiliser des moyens simples pour accéder à vos ordinateurs. Respectez les règles ci-dessous.

• Effectuez des sauvegardes fréquentes et sécurisez-les physiquement.

• Sécurisez physiquement votre ordinateur serveur Web de sorte qu'aucun utilisateur non autorisé ne puisse y accéder, l'éteindre ou l'emporter.

• Utilisez le système de fichiers NTFS et non pas FAT32. Le système NTFS offre une sécurité considérablement plus élevée que FAT32. Pour plus d'informations, consultez la documentation Windows.

• Sécurisez l'ordinateur serveur Web ainsi que l'ensemble des ordinateurs du réseau à l'aide de mots de passe forts.

• Sécurisez IIS. Pour plus d'informations, consultez le site Web Microsoft TechNet Security Center.

• Fermez les ports non utilisés et désactivez les services non utilisés.

• Exécutez un antivirus qui surveille les trafics entrant et sortant.

• Établissez et mettez en place une politique interdisant aux utilisateurs de conserver une trace écrite de leur mot de passe à un endroit facile à trouver.

• Utilisez un pare-feu. Pour obtenir des recommandations, consultez Microsoft Firewall Guidelines sur le site Web Microsoft consacré à la sécurité.

• Installez les derniers correctifs de sécurité proposés par Microsoft et les autres fournisseurs. Par exemple, le site Web Microsoft TechNet Security Center propose la liste des derniers bulletins de sécurité de tous les produits Microsoft. D'autres fournisseurs proposent des sites similaires.

• Utilisez les journaux des événements de Windows et examinez-les fréquemment pour détecter toute activité suspecte. Surveillez, entre autres, les tentatives de connexion répétées à votre système et les nombres élevés de demandes auprès de votre serveur Web.

Exécution des applications avec les privilèges les plus faibles possible

Votre application s'exécute dans un contexte disposant de privilèges spécifiques sur l'ordinateur local et, le cas échéant, sur des ordinateurs distants. Pour plus d'informations sur la configuration de l'identité de l'application, consultez Configuration de l'identité de processus ASP.NET. Pour lancer une exécution avec les privilèges les plus faibles, respectez les indications suivantes :

• N'exécutez pas votre application avec l'identité d'un utilisateur système (administrateur).

• Exécutez l'application dans le contexte d'un utilisateur ayant les privilèges les plus faibles possible.

• Définissez les autorisations (ACL ou listes de contrôle d'accès) sur toutes les ressources requises pour votre application. Utilisez le paramètre le plus strict. Par exemple, définissez, dans la mesure du possible, les fichiers comme étant en lecture seule. Pour obtenir la liste des autorisations ACL minimales requises pour l'identité de votre application ASP.NET, consultez Listes de contrôle d'accès requis par ASP.NET.

• Conservez les fichiers de votre application Web dans un dossier au-dessous de la racine de l'application. Ne permettez pas aux utilisateurs de spécifier un chemin d'accès de fichier dans votre application. Ceci permet d'éviter qu'ils n'accèdent à la racine de votre serveur.

Connaissance des utilisateurs

Dans beaucoup d'applications, les utilisateurs accèdent anonymement (sans devoir fournir les informations d'identification) au site. Si c'est le cas pour votre application, elle accède aux ressources en s'exécutant dans le contexte d'un utilisateur prédéfini. Par défaut, ce contexte est celui de l'utilisateur local ASPNET (sous Windows 2000 ou Windows XP) ou de l'utilisateur SERVICE RÉSEAU (sous Windows Server 2003) de l'ordinateur serveur Web. Pour restreindre l'accès aux utilisateurs authentifiés, appliquez les règles ci-dessous.

• Si votre application est une application intranet, configurez-la de sorte qu'elle utilise la sécurité intégrée de Windows. Les informations d'identification de connexion de l'utilisateur pourront ainsi être utilisées pour accéder aux ressources. Pour plus d'informations, consultez Emprunt d'identité ASP.NET.

• S'il vous faut obtenir les informations d'identification de l'utilisateur, utilisez l'une des stratégies d'authentification ASP.NET. Pour obtenir un exemple, consultez Gestion des utilisateurs à l'aide de l'appartenance.

Protection contre les entrées d'utilisateur nuisibles

Ne considérez jamais que les entrées des utilisateurs sont sûres. Les utilisateurs malveillants peuvent très facilement envoyer des informations dangereuses en provenance du client vers votre application. Pour vous protéger des entrées nuisibles, appliquez les règles ci-dessous.

• Dans les pages Web ASP.NET, filtrez les entrées d'utilisateur pour vérifier les balises HTML, susceptibles de contenir un script. Pour plus d'informations, consultez Comment : se protéger contre les attaques de script dans une application Web en utilisant le codage HTML.

• Ne reproduisez (n'affichez) jamais des entrées d'utilisateur non filtrées. Avant d'afficher des informations non fiables, codez le HTML pour convertir le script potentiellement nuisible en chaînes d'affichage.

• Ne stockez jamais des entrées d'utilisateur non filtrées dans une base de données.

• Si vous souhaitez accepter du HTML provenant d'un utilisateur, filtrez-le manuellement. Dans votre filtre, définissez explicitement les éléments à accepter. Ne créez pas de filtre visant à filtrer les entrées nuisibles, car il est extrêmement difficile de prendre en compte toutes les entrées nuisibles possibles.

• Ne présupposez pas que les informations obtenues dans un en-tête de demande HTTP (dans l'objet HttpRequest) sont sûres. Utilisez des protections pour les chaînes de requête, cookies, etc. Les informations transmises au serveur par le navigateur (informations de l'agent utilisateur (user agent)) peuvent être usurpées, ce qui peut nuire à votre application.

• Dans la mesure du possible, ne stockez pas d'informations sensibles à un emplacement accessible à partir du navigateur, tel qu'un champ masqué ou un cookie. Par exemple, ne stockez jamais un nom d'utilisateur ou un mot de passe dans un cookie.

  Remarque :

  L'état d'affichage est stocké dans un champ masqué sous un format codé. Par défaut, il comprend un code d'identification des messages (MAC, Message Authentication Code) permettant à la page est de déterminer si l'état d'affichage a fait l'objet d'une falsification. Si des informations sensibles sont stockées dans l'état d'affichage, chiffrez-les en définissant la propriété ViewStateEncryptionMode de la page avec la valeur true.

Accès sécurisé aux bases de données

Les bases de données disposent généralement de leur propre sécurité. La sécurisation de l'accès à la base de données représente un aspect important de la sécurisation des applications Web. Respectez les règles ci-dessous.

• Utilisez la sécurité propre à votre base de données pour limiter l'accès à ses ressources. La stratégie exacte à appliquer dépend de votre base de données et de votre application :

  • Si possible, utilisez la sécurité intégrée de sorte que seuls les utilisateurs authentifiés par Windows puissent accéder à la base de données. La sécurité intégrée est plus sécurisée que le passage d'informations d'identification explicites à la base de données.

  • Si votre application implique l'accès anonyme, créez un utilisateur unique disposant d'autorisations restreintes et effectuez les requêtes en vous connectant en tant que cet utilisateur.

• Ne créez pas d'instructions SQL en concaténant des chaînes impliquant une entrée d'utilisateur. Créez plutôt une requête paramétrée et utilisez l'entrée d'utilisateur pour définir les valeurs de paramètre.

• Si vous devez stocker quelque part un nom d'utilisateur et un mot de passe à utiliser comme informations d'identification de connexion de base de données, stockez-les dans le fichier Web.config et sécurisez le fichier avec une configuration protégée. Pour plus d'informations, consultez Chiffrement des informations de configuration à l'aide de la configuration protégée.

Pour plus d'informations sur l'accès sécurisé aux données, consultez Sécurisation de l'accès aux données et Sécurisation des applications ADO.NET.

Création de messages d'erreur sécurisés

Si vous n'êtes pas prudent, un utilisateur malveillant peut déduire des informations importantes sur votre application à partir des messages d'erreur qui s'affichent. Respectez les règles ci-dessous.

• N'écrivez pas de messages d'erreurs reproduisant des informations pouvant être utilisées par des utilisateurs malveillants, telles qu'un nom d'utilisateur.

• Configurez l'application de façon à ne pas afficher d'erreurs détaillées. Si vous souhaitez afficher des messages d'erreur détaillés pour le débogage, déterminez d'abord s'il s'agit d'un utilisateur local du serveur Web. Pour plus d'informations, consultez Comment : afficher des messages d'erreur sécurisés.

• Utilisez l'élément de configuration customErrors pour contrôler les personnes qui peuvent consulter les exceptions à partir du serveur.

• Créez une gestion des erreurs personnalisée pour les situations sujettes aux erreurs, telles que l'accès aux bases de données. Pour plus d'informations, consultez Gestion des erreurs dans les pages et les applications ASP.NET.

Sécuriser les informations sensibles

Les informations sensibles sont toutes les informations dont vous devez préserver la confidentialité. Les mots de passe et les clés de chiffrement en sont des exemples types. Si un utilisateur malveillant parvient à y accéder, les données protégées par le secret sont compromises. Respectez les règles ci-dessous.

• Si votre application transmet des informations sensibles entre le navigateur et le serveur, envisagez d'utiliser SSL (Secure Sockets Layer). Pour plus d'informations sur la sécurisation d'un site avec SSL, consultez l'article Q307267, « COMMENT FAIRE : Sécuriser des services Web XML avec SSL », de la Base de connaissances Microsoft, à l'adresse https://www.microsoft.com/france/support.

• Utilisez la configuration protégée pour sécuriser les informations sensibles dans les fichiers de configuration tels que les fichiers Web.config ou Machine.config. Pour plus d'informations, consultez Chiffrement des informations de configuration à l'aide de la configuration protégée.

• Si vous devez stocker des informations sensibles, ne les conservez pas dans une page Web, même si vous pensez que les utilisateurs ne seront pas en mesure de les afficher (sous forme de code serveur, par exemple).

• Utilisez les algorithmes de chiffrement renforcé fournis dans l'espace de noms System.Security.Cryptography.

Utilisation sécurisée des cookies

Les cookies sont un moyen utile de conserver des informations propres à l'utilisateur de façon accessible. Toutefois, étant donné que les cookies sont envoyés à l'ordinateur sur lequel s'exécute le navigateur, ils sont vulnérables face à l'usurpation ou à d'autres utilisations malveillantes. Respectez les règles ci-dessous.

• Ne stockez aucune information sensible dans des cookies. Par exemple, ne stockez jamais un mot de passe dans un cookie, même de façon temporaire. À titre de règle, ne conservez rien dans un cookie qui, s'il était rendu factice, pourrait compromettre votre application. Conservez plutôt une référence, dans le cookie, à l'emplacement des informations sur le serveur.

• Définissez des délais d'expiration les plus courts possible pour les cookies. Dans la mesure du possible, évitez toujours les cookies permanents.

• Envisagez de chiffrer les informations dans les cookies.

• Pensez à définir les propriétés Secure et HttpOnly sur le cookie avec la valeur true.

Protection contre les menaces de déni de service

Un utilisateur malveillant peut compromettre votre application de manière indirecte en la rendant non disponible. Il peut faire en sorte qu'elle soit trop occupée pour servir les autres utilisateurs ou tout simplement l'arrêter. Respectez les règles ci-dessous.

• Utilisez une gestion des erreurs (telle que try-catch). Insérez un bloc finally dans lequel vous libérez les ressources en cas d'échec.

• Configurez IIS pour utiliser la limitation des processus qui empêche les applications d'utiliser une quantité disproportionnée de temps CPU.

• Vérifiez la limite de taille des entrées d'utilisateur avant de les utiliser ou de les stocker.

• Appliquez des protections de taille aux requêtes de base de données. Par exemple, avant d'afficher les résultats d'une requête dans une page Web ASP.NET, vérifiez que le nombre d'enregistrements est raisonnable.

• Appliquez une limite de taille aux transferts de fichiers faisant partie de votre application. Vous pouvez définir une limite dans le fichier Web.config à l'aide d'une syntaxe semblable à la suivante, la valeur maxRequestLength étant exprimée en kilooctets :

  <configuration>
     <system.web>
          <httpRuntime maxRequestLength="4096" />
     </system.web>
  </configuration>
  

  Vous pouvez également utiliser la propriété RequestLengthDiskThreshold pour réduire la mémoire occupée par des téléchargements et des publications de formulaire volumineux.

Voir aussi

Concepts

Vue d'ensemble des menaces de sécurité des applications Web