Série de conférences ASP (vingt) Maintenir la sécurité des applications ASP
Auteur：Eve Cole
Date de mise à jour：2009-05-30 19:58:35
Ne sous-estimez jamais l’importance de configurer correctement les paramètres de sécurité. Une configuration incorrecte des paramètres de sécurité expose non seulement vos applications ASP à des falsifications inutiles, mais empêche également les utilisateurs légitimes d'accéder à vos fichiers .asp.
Les serveurs Web proposent diverses méthodes pour protéger vos applications ASP contre les accès non autorisés et la falsification. Après avoir lu les informations de sécurité contenues dans cette rubrique, prenez un moment pour examiner attentivement la documentation sur la sécurité de votre serveur Windows NT et Web.
Autorisations NTFS Vous pouvez protéger les fichiers d'application ASP en appliquant des autorisations d'accès NTFS à des fichiers et répertoires individuels. Les autorisations NTFS constituent le fondement de la sécurité du serveur Web, définissant différents niveaux d'accès aux fichiers et répertoires pour un utilisateur ou un groupe d'utilisateurs. Lorsqu'un utilisateur disposant d'un compte Windows NT valide tente d'accéder à un fichier avec des autorisations restreintes, l'ordinateur vérifie la liste de contrôle d'accès (ACL) du fichier. Ce tableau définit les autorisations accordées aux différents utilisateurs et groupes d'utilisateurs. Si le compte de l'utilisateur est autorisé à ouvrir le fichier, l'ordinateur autorise l'utilisateur à accéder au fichier. Par exemple, le propriétaire d'une application Web sur un serveur Web a besoin des autorisations Modifier pour afficher, modifier et supprimer les fichiers .asp de l'application. Cependant, les utilisateurs publics accédant à l'application ne doivent disposer que d'autorisations en lecture seule, les limitant à l'affichage mais pas à la modification des pages Web de l'application.
Maintien de la sécurité Global.asa Pour protéger entièrement votre application ASP, veillez à définir les autorisations de fichier NTFS sur le fichier Global.asa de l'application pour l'utilisateur ou le groupe approprié. Si Global.asa contient des commandes qui renvoient des informations au navigateur et que vous ne protégez pas le fichier Global.asa, les informations seront renvoyées au navigateur même si d'autres fichiers de l'application sont protégés.
REMARQUE Assurez-vous d'appliquer des autorisations NTFS uniformes aux fichiers de l'application. Par exemple, si vous limitez accidentellement les autorisations NTFS pour un fichier qu'une application doit contenir, les utilisateurs risquent de ne pas pouvoir afficher ou exécuter l'application. Pour éviter de tels problèmes, planifiez soigneusement avant d'attribuer des autorisations NTFS à vos applications.
Autorisations du serveur Web Vous pouvez restreindre la façon dont tous les utilisateurs peuvent afficher, exécuter et manipuler vos pages ASP en configurant les autorisations sur votre serveur Web. Contrairement aux autorisations NTFS, qui permettent de contrôler l'accès d'utilisateurs spécifiques aux fichiers et répertoires d'application, les autorisations du serveur Web s'appliquent à tous les utilisateurs et ne font pas de différence entre les types de comptes utilisateur.
Pour les utilisateurs qui exécuteront vos applications ASP, vous devez suivre ces directives lors de la définition des autorisations du serveur Web :
Autorisez les autorisations de lecture ou de script sur le répertoire virtuel contenant le fichier .asp.
Autorisez les autorisations « lecture » et « script » sur les répertoires virtuels où se trouvent les fichiers .asp et autres fichiers contenant des scripts (tels que les fichiers .htm, etc.).
Autorisez les autorisations de lecture et d'exécution sur les répertoires virtuels contenant des fichiers .asp et d'autres fichiers nécessitant des autorisations d'exécution pour s'exécuter (tels que les fichiers .exe et .dll, etc.).
Fichiers de mappage de script Le mappage de script de l'application garantit que le serveur Web ne télécharge pas accidentellement le code source du fichier .asp. Par exemple, même si vous définissez des autorisations de lecture pour le répertoire contenant un fichier .asp, votre serveur Web ne renverra pas le code source du fichier tant que le fichier .asp appartient à une application de mappage de scripts pour les utilisateurs.
Sécurité des cookies
ASP utilise le cookie SessionID pour suivre les informations spécifiques du navigateur Web lors d'une visite ou d'une session d'application. Cela signifie que les requêtes HTTP avec les cookies correspondants sont considérées comme provenant du même navigateur Web. Les serveurs Web peuvent utiliser les cookies SessionID pour configurer les applications ASP avec des informations de session spécifiques à l'utilisateur. Par exemple, si votre application est un magasin de musique en ligne qui permet aux utilisateurs de sélectionner et d'acheter des CD, vous pouvez utiliser SessionID pour suivre les sélections de l'utilisateur lorsqu'il parcourt l'application.
Les pirates peuvent-ils deviner l'ID de session ?
Pour empêcher les pirates informatiques de deviner le cookie SessionID et d'accéder aux variables de session d'un utilisateur légitime, le serveur Web attribue un numéro généré aléatoirement à chaque SessionID. Chaque fois que le navigateur Web de l'utilisateur renvoie un cookie SessionID, le serveur récupère le SessionID et le numéro attribué, puis vérifie s'il correspond au numéro généré stocké sur le serveur. Si les deux nombres correspondent, l'utilisateur sera autorisé à accéder à la variable de session. L'efficacité de cette technique réside dans la longueur du numéro attribué (64 bits), ce qui rend presque nulle la possibilité pour un pirate informatique de deviner le SessionID et de voler la session active de l'utilisateur.
Crypter le cookie SessionID important
Un pirate informatique qui intercepte le cookie d'identification de session d'un utilisateur peut utiliser ce cookie pour usurper l'identité de l'utilisateur. Si une application ASP contient des informations privées, des numéros de carte de crédit ou de compte bancaire, un pirate informatique disposant d'un cookie volé peut démarrer une session active dans l'application et obtenir ces informations. Vous pouvez empêcher l'interception du cookie SessionID en cryptant le lien de communication entre votre serveur Web et le navigateur de l'utilisateur.
Protection du contenu ASP restreint à l'aide de mécanismes d'authentification Vous pouvez exiger que chaque utilisateur qui tente d'accéder au contenu ASP restreint dispose d'un nom d'utilisateur et d'un mot de passe de compte Windows NT valides. Chaque fois qu'un utilisateur tente d'accéder à un contenu restreint, le serveur Web effectue une authentification ou une vérification de l'identité de l'utilisateur pour vérifier si l'utilisateur dispose d'un compte Windows NT valide.
Le serveur Web prend en charge les méthodes d'authentification suivantes :
Authentification de base Demande à l'utilisateur un nom d'utilisateur et un mot de passe.
L'authentification demande/réponse Windows NT obtient de manière cryptée les informations d'identité de l'utilisateur à partir du navigateur Web de l'utilisateur.
Toutefois, le serveur Web authentifie l'utilisateur uniquement si l'accès anonyme est interdit ou restreint par les autorisations du système de fichiers Windows NT.
Sécurisation de la métabase Les scripts ASP qui accèdent à la métabase nécessitent des droits d'administrateur sur l'ordinateur sur lequel le serveur Web est exécuté. Lors de l'exécution de ces scripts à partir d'un ordinateur distant, vous devez vous connecter via une connexion authentifiée, par exemple en utilisant l'authentification demande/réponse Windows NT. Vous devez créer un serveur ou un répertoire pour le fichier administratif .asp et définir sa méthode d'authentification de sécurité de répertoire sur l'authentification demande/réponse Windows NT. Actuellement, l'authentification demande/réponse Windows NT n'est prise en charge que par Microsoft Internet Explorer version 2.0 ou ultérieure.
Maintenir la sécurité des applications à l’aide de SSL
En tant que fonctionnalité de sécurité du serveur Web, le protocole Secure Sockets Layer (SSL) 3.0 fournit un moyen virtuel sécurisé et transparent d'établir des connexions de communication cryptées avec les utilisateurs. SSL garantit l'authentification du contenu Web et peut confirmer de manière fiable l'identité des utilisateurs accédant à des sites Web restreints.
Avec SSL, vous pouvez demander aux utilisateurs essayant d'accéder à des applications ASP restreintes d'établir une connexion cryptée avec votre serveur ; cela empêche l'interception des informations importantes échangées entre les utilisateurs et les applications.
Maintien de la sécurité des fichiers inclus Si vous incluez des fichiers situés dans un répertoire compatible SSL à partir d'un fichier .asp situé dans un répertoire racine virtuel non protégé, SSL ne sera pas appliqué aux fichiers inclus. Par conséquent, pour garantir que SSL est appliqué, assurez-vous que les fichiers inclus et inclus se trouvent dans un répertoire compatible SSL.
Authentification client Un moyen très sécurisé de contrôler l'accès à votre application ASP consiste à exiger que les utilisateurs se connectent avec l'authentification client. Un identifiant client est une carte d’identité numérique qui contient les informations d’identité de l’utilisateur et fonctionne de la même manière qu’une forme d’identification traditionnelle telle qu’un passeport ou un permis de conduire. Les utilisateurs obtiennent généralement les qualifications des clients auprès d'un organisme tiers agréé, qui confirme les informations d'identité de l'utilisateur avant de délivrer des certificats de qualification. (En règle générale, ces organisations demandent un nom, une adresse, un numéro de téléphone et le nom de l'organisation ; le niveau de détail de ces informations varie en fonction du niveau de statut attribué.)
Chaque fois qu'un utilisateur tente de se connecter à une application nécessitant une vérification d'éligibilité, le navigateur Web de l'utilisateur envoie automatiquement ses informations d'identification au serveur. Si la fonctionnalité de mappage de qualification SSL (Secure Sockets Layer) du serveur Web est configurée correctement, le serveur peut vérifier l'identité d'un utilisateur avant d'accorder l'accès à une application ASP.
Scripts ASP pour gérer la certification des qualifications En tant que développeur d'applications ASP, vous pouvez écrire des scripts pour vérifier si une qualification existe et lire les champs de qualification. Par exemple, vous pouvez accéder au champ Nom d'utilisateur et au champ Nom de l'entreprise à partir de la qualification. Active Server Pages stocke les informations de qualification dans la collection ClientCertificate de l'objet Request.
Le serveur Web doit être configuré pour accepter ou exiger les qualifications du client avant de pouvoir être traité via ASP ; sinon, la collection ClientCertificate sera vide.
