Sécurité des applications Web au moment de l'exécution

Article
10/22/2014

Mise à jour : novembre 2007

Le développement de votre application exige que vous examiniez un ensemble de questions relatives à la sécurité. L'autre ensemble de questions (celles généralement plus importantes dans toute discussion liée à la sécurité sur le Web) concernent la sécurité de l'application lorsqu'elle est déployée et en cours d'exécution.

Par définition, les applications Web permettent aux utilisateurs d'accéder à une ressource centrale, le serveur Web et, via celui-ci, à d'autres ressources, telles que les serveurs de bases de données. En maîtrisant et en implémentant les mesures de sécurité appropriées, vous :

protégez vos propres ressources contre un accès non autorisé ;
limitez les niveaux d'accès par utilisateur ou rôle ;
établissez l'intégrité et la confidentialité des données, ce qui offre un environnement relativement sécurisé dans lequel les utilisateurs peuvent employer aisément votre application ;
contrôlez les moyens d'accès de votre application aux ressources limitées ;
vérifiez que le code de l'application s'exécute comme prévu.

Cette rubrique propose une présentation générale des opérations permettant d'atteindre ces objectifs, et des liens vers d'autres rubriques où vous pouvez en savoir plus sur les technologies impliquées.

Vous pouvez protéger votre application contre un accès non autorisé en tirant parti de ces types de fonctionnalités de sécurité :

Fonctionnalités de sécurité offertes par IIS, parmi ses fonctions générales relatives au serveur Web. Elles comprennent la sécurité au niveau utilisateur, de l'ordinateur et des fichiers Windows.
Sécurité que vous pouvez intégrer dans votre application ASP.NET pour offrir un accès propre à l'application.

Processus de sécurité dans ASP.NET

IIS fournit un grand nombre d'options de sécurité pour les sites Web. Toutefois, les mécanismes de sécurité IIS sont très génériques, dans la mesure où les mêmes sont utilisés pour toutes les applications. En outre, les options de sécurité IIS, telles que l'utilisation de la sécurité intégrée de Windows, peuvent ne pas toujours convenir à votre application. (En revanche, pour les applications intranet, vous pouvez utiliser la sécurité intégrée de Windows pour plus de simplicité.)

Par conséquent, afin d'offrir un accès à des parties spécifiques de votre application, vous pouvez utiliser la sécurité ASP.NET. Celle-ci fonctionne avec la sécurité IIS, mais l'étend afin que vous puissiez personnaliser des fonctionnalités, telles que le mode d'obtention des informations d'identification de l'utilisateur.

IIS reçoit d'abord les demandes des clients et effectue toutes les vérifications de sécurité établies pour votre application à l'aide des outils de gestion IIS. Par exemple, si l'application a été configurée dans IIS pour autoriser l'accès anonyme, IIS n'effectue aucune vérification des informations d'identification. Après avoir effectué cette première vérification de l'authentification, IIS envoie la demande à ASP.NET, qui peut procéder à une deuxième vérification. ASP.NET vous permet d'indiquer des restrictions d'accès à votre application à l'aide de nombreux critères : vous pouvez, par exemple, limiter l'accès à des pages ou à des utilisateurs spécifiques.

Authentification

Le tableau suivant décrit les méthodes d'authentification qui sont prises en charge par ASP.NET, dont plusieurs rejoignent les méthodes d'authentification IIS. Pour plus d'informations, consultez Authentification ASP.NET.

Type d'authentification	Description
Accès anonyme	Dans le cas d'applications où des utilisateurs inconnus effectuent des demandes (en règle générale, les applications Web publiques). Commune avec IIS.
Authentification de base et Digest	Option de sécurité IIS. Dans ce scénario, les utilisateurs sans informations d'identification sont invités à fournir un nom d'utilisateur et un mot de passe.
Sécurité intégrée Windows (également connue sous le nom de sécurité NTLM)	Option de sécurité IIS. Si l'utilisateur effectuant la demande a déjà été authentifié sur un réseau Windows, IIS peut y passer ses informations d'identification lors d'une demande d'accès à une ressource.
Authentification par certificat	Option de sécurité IIS. Dans ce scénario, le client dispose d'un certificat (une identification numérique) obtenu auprès d'une source tierce. L'identité mappée au certificat client est passée à ASP.NET.
Kerberos	Option de sécurité IIS. Le protocole d'authentification Kerberos définit les interactions entre un client et un service d'authentification réseau appelé centre de distribution de clés (KDC, Key Distribution Center). Windows 2000 et 2003 implémentent un centre de distribution de clés comme service d'authentification sur chaque contrôleur de domaine.
Authentification Windows	Option de sécurité IIS. S'intègre avec les options de sécurité IIS précédemment répertoriées. ASP.NET accepte le jeton de sécurité créé par IIS et le rend disponible en tant qu'objet WindowsPrincipal défini comme valeur de la propriété User du HttpContext actuel.
Authentification par formulaire	Option de sécurité. Si un utilisateur doit être authentifié, ASP.NET redirige la demande vers une page que vous indiquez. Cette page contient généralement un formulaire dans lequel vous obtenez les informations sur le nom d'utilisateur. (Pour plus de sécurité, le formulaire peut être échangé à l'aide du protocole HTTPS.) Lorsque votre application reçoit les informations du formulaire, elle peut effectuer une vérification propre à l'application des informations d'identification de l'utilisateur. Il est important de noter que le processus d'authentification est sous votre contrôle (à la différence de IIS), ce qui vous permet de définir l'aspect du formulaire et le mode de stockage des informations sur l'utilisateur. Si un utilisateur est authentifié avec succès, ASP.NET émet un cookie chiffré contenant un jeton qui identifie l'utilisateur pour l'accès suivant.

L'authentification par formulaires est le choix le plus facile pour les applications ASP.NET sur Internet, car il vous donne le contrôle substantiel sur la manière dont les utilisateurs sont authentifiés et vous permet de stocker l'authentification dans un jeton sur le navigateur.

Pour plus d'informations sur la sécurité IIS, consultez les rubriques de contrôle d'accès sur Windows Server TechCenter for IIS sur le site Web Microsoft TechNet. Pour plus d'informations sur l'authentification ASP.NET, consultez Authentification ASP.NET.

Pour plus d'informations sur l'utilisation de l'authentification par formulaires avec la transition de protocole et la délégation contrainte dans un environnement de domaine Windows Server 2003, consultez Kerberos Protocol Transition and Constrained Delegation.

Autorisation

Lors de son exécution, votre application Web demande des ressources au serveur Web et, souvent, à d'autres processus, tels qu'une base de données. Le processus ASP.NET s'exécute dans un contexte utilisateur qui détermine la façon dont votre application demande ces ressources. Le processus ASP.NET s'exécute comme utilisateur local spécial nommé ASPNET (par défaut) sur Windows 2000 et Windows XP Professionnel Edition ou comme identité du pool d'applications pour l'application ASP.NET sur Windows 2003 (par défaut, le compte SERVICE RÉSEAU local). Ces comptes s'exécutent avec des autorisations limitées. Vous pouvez spécifier un autre contexte utilisateur pour le processus ASP.NET, y compris le compte SYSTEM local (qui exécute votre application dans un contexte administrateur) ou un utilisateur pour lequel vous fournissez explicitement les informations d'identification, bien que cela ne soit pas recommandé.

Dans votre application ASP.NET, vous pouvez indiquer que différents utilisateurs ont l'autorisation d'accéder à différentes ressources. Si votre application utilise l'authentification Windows, les autorisations Windows vous permettent d'identifier l'autorisation pour accéder à des fichiers ou dossiers spécifiques sur le serveur.

Vous pouvez également utiliser l'autorisation basée sur URL, par laquelle l'autorisation peut être accordée ou refusée en fonction de différents critères :

utilisateurs spécifiques, ou identités, basés sur les informations d'identification fournies par l'utilisateur ;
rôles, qui sont des entités définies pour permettre à plusieurs utilisateurs de partager des privilèges selon une fonction ou un rôle commun ;
verbes, qui sont les processus HTTP (tels que GET et POST) d'accès à des parties de votre application.

Par exemple, vous pouvez indiquer que tous les utilisateurs peuvent obtenir des pages (exécuter le verbe GET) de votre application, mais que seuls certains utilisateurs peuvent les y publier. De même, vous pouvez spécifier que tous les utilisateurs sont autorisés à obtenir des pages, mais que le droit de publication est refusé à des rôles spécifiques.

Vous pouvez accorder l'autorisation basée sur URL sur l'application dans son intégralité ou sur certains répertoires. Un exemple d'utilisation classique est de permettre à tous les utilisateurs d'afficher des pages dans un répertoire public, mais de conserver certaines pages dans un autre répertoire auquel ne peuvent accéder que des utilisateurs ou rôles spécifiques.

Remarque :
Par défaut, les fichiers statiques, tels que les images et les feuilles de style, ne sont pas soumis à l'autorisation ASP.NET lorsqu'ils sont pris en charge par IIS. Vous pouvez utiliser des fonctionnalités de sécurité IIS pour restreindre l'accès aux fichiers statiques si vous ne souhaitez pas que tous les utilisateurs puissent accéder aux fichiers. Si vous utilisez le serveur de développement ASP.NET pour tester votre application ASP.NET, vous pourrez remarquer un comportement différent parce que les fichiers statiques sont soumis à l'autorisation ASP.NET et ne seront pas fournis à un utilisateur anonyme lorsque l'accès anonyme à ces fichiers est désactivé. Vous pouvez également mapper des extensions de nom de fichier statique dans IIS à l'extension ISAPI ASP.NET, auquel cas les règles d'autorisation ASP.NET seront appliquées.

Par défaut, les fichiers statiques, tels que les images et les feuilles de style, ne sont pas soumis à l'autorisation ASP.NET lorsqu'ils sont pris en charge par IIS. Vous pouvez utiliser des fonctionnalités de sécurité IIS pour restreindre l'accès aux fichiers statiques si vous ne souhaitez pas que tous les utilisateurs puissent accéder aux fichiers. Si vous utilisez le serveur de développement ASP.NET pour tester votre application ASP.NET, vous pourrez remarquer un comportement différent parce que les fichiers statiques sont soumis à l'autorisation ASP.NET et ne seront pas fournis à un utilisateur anonyme lorsque l'accès anonyme à ces fichiers est désactivé. Vous pouvez également mapper des extensions de nom de fichier statique dans IIS à l'extension ISAPI ASP.NET, auquel cas les règles d'autorisation ASP.NET seront appliquées.

Pour plus d'informations, consultez Autorisation ASP.NET et Méthodes de sécurité de base pour les applications Web.

Fichiers de configuration ASP.NET

Vous choisissez des options de sécurité ASP.NET en utilisant les paramètres d'un fichier Web.config. Ce fichier vous permet d'inclure des éléments prédéfinis pour différentes options de sécurité, y compris les sections relatives à l'authentification et à l'autorisation. Les sections pertinentes du fichier Web.config peuvent se présenter comme suit :

<configuration>
  <system.web>
    <authentication mode="Forms">
      <forms loginUrl="login.aspx" />
    </authentication>
    <authorization>
      <deny user="?" />
    </authorization>
  </system.web>
</configuration>

Votre application peut contenir plusieurs fichiers de configuration. Par défaut, un fichier de configuration situé à la racine de l'application spécifie la sécurité de l'application dans son intégralité (autrement dit, les paramètres de sécurité sont hérités par les sous-dossiers). Toutefois, vous pouvez également créer des fichiers de configuration dans des dossiers individuels pour établir des paramètres de sécurité pour ces dossiers.

Pour plus d'informations, consultez Architecture ASP.NET.

Sécurité des services Web XML

Les services Web XML utilisant les fichiers .asmx s'exécutent comme des applications Web à l'aide de ASP.NET et font donc partie du même modèle de sécurité que toute application ASP.NET. Par exemple, un service Web XML peut être configuré pour utiliser l'authentification de base ou la sécurité intégrée de Windows.

Au moment du design, lorsque vous tentez d'ajouter une référence à un service Web XML (autrement dit, lorsque vous demandez ses documents de découverte), celui-ci exécute l'authentification de l'application Web standard en fonction de sa configuration. Par exemple, si le service Web XML est configuré pour utiliser l'authentification de base, il attend de recevoir un nom d'utilisateur et un mot de passe du client qui effectue la demande. Si le service Web XML utilise l'authentification de base, par exemple, la boîte de dialogue Ajouter une référence Web vous demande les informations d'identification.

Si vous créez une application qui comprend des appels à un service Web XML, vous devez vous assurer que vos informations d'identification sont correctes avant d'effectuer l'appel ou celui-ci échouera. Au moment de l'exécution, vous pouvez passer les informations d'identification au service Web XML en définissant la propriété Credentials de l'objet côté client représentant le service Web XML avant d'appeler ses méthodes.

Les autres options de sécurité ASP.NET pouvant ne pas être suffisamment souples, les services Web XML peuvent implémenter une solution d'authentification personnalisée où les informations d'identification sont transmises dans des en-têtes SOAP. Dans cette solution, ces informations sont transmises dans une partie facultative du message échangé entre le client et le serveur. Vous pouvez alors écrire un module HTTP personnalisé (implémentant l'interface IHttpModule) qui peut écouter les informations dans l'en-tête et appeler votre code d'authentification.

Comme avec d'autres applications ASP.NET, le service Web XML peut implémenter des autorisations basées sur les rôles spécifiques pour limiter l'accès à certaines parties de l'application.

Pour plus d'informations, consultez Infrastructure des services Web XML et Sécurisation des services Web XML créés à l'aide d'ASP.NET.

Établissement de l'intégrité et de la confidentialité des données

L'authentification et l'autorisation établissent l'identité de vos utilisateurs et les ressources auxquelles ils peuvent accéder. Ces fonctionnalités de sécurité sont conçues principalement pour contribuer à la protection de votre application Web contre une utilisation non autorisée.

Toutefois, il existe aussi un autre aspect de la sécurité, qui est de protéger les informations des utilisateurs et de leur offrir la confiance de pouvoir échanger des informations confidentielles avec vous. Par exemple, si votre application demande aux utilisateurs le numéro de leur carte de crédit ou d'autres comptes, des informations personnelles ou toute autre donnée qu'ils ne veulent pas divulguer, vous devez leur offrir un moyen de vous envoyer ces informations en toute sécurité.

Vous pouvez utiliser le SSL (Secure Sockets Layer) dans IIS pour échanger des informations chiffrées à l'aide du protocole HTTPS. SSL fournit le chiffrement dans les deux directions : vos informations sont transmises à l'utilisateur à l'aide du chiffrement et les informations que l'utilisateur publie dans votre application sont également chiffrées.

Mise en place de SSL et du chiffrement

Pour utiliser SSL et le chiffrement, vous devez vous procurer un certificat serveur pour votre société ou identité. Le certificat est une signature numérique qui donne à votre site une identité qui ne peut pas être usurpée. Pour les applications Internet (publiques), vous vous procurez un certificat serveur auprès d'une autorité de certification tierce reconnue. Pour les applications privées (intranet), vous pouvez émettre un certificat serveur vous-même. Vous pouvez le faire pour sécuriser une application interne, telle qu'un site personnel.

Votre certificat serveur permet également d'installer des connexions chiffrées par SSL aux utilisateurs du navigateur. SSL utilise une méthode de chiffrement appelée chiffrement à clé publique. Dans cette forme de chiffrement, il existe deux clés : une clé publique utilisée pour chiffrer les données et une clé privée tenue secrète et utilisée pour déchiffrer les informations chiffrées avec la clé publique. Le certificat serveur que vous vous êtes procuré contient une clé publique. Lorsque les utilisateurs veulent employer SSL, votre application envoie le certificat et la clé publique au navigateur. Le navigateur et le serveur utilisent alors la clé publique pour élaborer une façon de chiffrer leur échange d'informations.

Remarque :
L'utilisation de SSL suppose que le navigateur prenne en charge une clé de chiffrement de 40 bits au moins. Ce niveau est disponible dans la plupart des navigateurs. Cependant, cette longueur de clé n'est pas considérée comme sécurisée. Vous pouvez éventuellement configurer votre application dans IIS pour autoriser uniquement les connexions SSL avec une clé de 128 bits.

Une fois que vous avez un certificat serveur, vous pouvez demander aux utilisateurs de se servir de SSL en utilisant le préfixe https:// pour obtenir et publier des pages Web. Votre site Web peut également être configuré dans IIS pour accepter uniquement les connexions HTTPS. IIS et le navigateur utilisent automatiquement un canal chiffré pour échanger les informations.

Pour plus d'informations sur l'utilisation de SSL, consultez l'article Q307267, « COMMENT FAIRE : Sécuriser des services Web XML avec SSL » de la Base de connaissances Microsoft. Pour plus d'informations sur le chiffrement, consultez Vue d'ensemble du chiffrement. Pour plus d'informations sur les certificats et sur la configuration de SSL, consultez Windows Server TechCenter for IIS sur le site Web Microsoft TechNet.

Utilisation de la sécurité du code .NET

Un dernier aspect de la sécurité consiste à faire en sorte que le code de l'application est protégé contre toute utilisation incorrecte, que ce soit une exécution accidentelle dans un contexte inapproprié ou une utilisation dans le but de nuire. Étant donné qu'ASP.NET fait partie du .NET Framework, vous pouvez également tirer parti de la sécurité d'accès du code pour établir des autorisations pour le code. Pour plus d'informations, consultez Sécurité d'accès du code.

Voir aussi

Concepts

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

Partager via