Exporter (0) Imprimer
Développer tout

Examen de la sécurité de l'architecture et de la conception

Dernière mise à jour le 31 août 2004
Sur cette page

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Processus d'examen de l'architecture et de la conception Processus d'examen de l'architecture et de la conception
Considérations relatives au déploiement et à l'infrastructure Considérations relatives au déploiement et à l'infrastructure
Validation des entrées Validation des entrées
Authentification Authentification
Autorisation Autorisation
Gestion de la configuration Gestion de la configuration
Données sensibles Données sensibles
Gestion des sessions Gestion des sessions
Cryptographie Cryptographie
Manipulation des paramètres Manipulation des paramètres
Gestion des exceptions Gestion des exceptions
Audit et journalisation Audit et journalisation
Résumé Résumé
Informations complémentaires Informations complémentaires

Dans ce module

Pour construire une application Web sécurisée, une architecture et une conception adaptées sont indispensables. Le coût et les efforts d'adaptation de la sécurité après le développement sont trop élevés. L'examen de l'architecture et de la conception vous aide à valider les fonctions de conception de votre application liées à la sécurité, avant le démarrage de la phase de développement. Ceci vous permet d'identifier et de corriger les vulnérabilités avant qu'elles ne soient exploitées, et avant que la correction ne requière des efforts inconsidérés de réingénierie.

Ce module pose les questions que vous devez vous poser lorsque vous examinez la conception de votre architecture en profondeur. Même si vous avez déjà créé votre application, vous pouvez lire ce module et réexaminer les concepts, les principes et les techniques que vous avez employés au moment de sa conception.

Objectifs

Ce module vous permettra :

  • De savoir poser les bonnes questions lors de l'examen en profondeur de la conception de votre architecture.

  • D'analyser l'architecture et la conception de votre application Web.

  • De développer et améliorer vos pratiques actuelles en matière d'examen de la sécurité.

  • De créer un processus de correction des vulnérabilités lors de la phase de conception.

  • D'identifier les aspects essentiels du déploiement de l'application et de la sécurité de l'infrastructure.

  • De veiller au déploiement correct et sécurisé de votre application Web.

S'applique à

Applications Web

Processus d'examen de l'architecture et de la conception

Ce processus analyse l'architecture et la conception du point de vue de la sécurité. Si vous venez de terminer la conception, sa documentation peut vous aider dans le déroulement de ce processus. Que la documentation de votre conception soit exhaustive ou non, vous devez pouvoir décomposer votre application et être capable d'identifier les principaux éléments, y compris les limites sécurisées, le flux des données, les points d'entrée et le code privilégié. Vous devez également connaître la configuration de déploiement physique de votre application. Soyez attentif aux approches de conception que vous avez adoptées dans les domaines qui présentent le plus souvent des vulnérabilités. Ce guide les désigne comme les catégories de vulnérabilités de l'application.

Tenez compte des aspects suivants lorsque vous examinez l'architecture et la conception de votre application :

  • Déploiement et infrastructure. Vous examinez la conception de votre application en relation à l'environnement de déploiement cible et aux stratégies de sécurité associées. Vous envisagez également les restrictions imposées par la sécurité de la couche d'infrastructure sous-jacente.

  • Architecture et conception de l'application. Vous examinez l'approche des domaines critiques de votre application, notamment l'authentification, l'autorisation, la validation des entrées, la gestion des exceptions, ainsi que d'autres domaines. Vous pouvez utiliser les catégories de vulnérabilités de l'application comme un plan d'action et pour vous assurer que vous n'oubliez aucun domaine essentiel lors de l'examen.

  • Analyse couche par couche. Vous parcourez les couches logiques de votre application et examinez la sécurité des pages Web et des contrôles ASP.NET, des services Web, des composants de service, de Microsoft .NET Remoting, du code d'accès aux données, etc.

La figure 5.1 illustre cette approche à trois facettes du processus d'examen.

Examen de l'application

Figure 5.1
Examen de l'application

Le reste de ce module présente les principales considérations et les questions à poser lors du processus d'examen pour chacun de ces domaines distincts.

Considérations relatives au déploiement et à l'infrastructure

Examinez les paramètres de sécurité offerts à l'application par l'infrastructure sous-jacente du réseau et de l'hôte, et examinez les éventuelles restrictions que l'environnement cible risque d'imposer. Étudiez également la topologie du déploiement et l'impact des serveurs d'application de la couche intermédiaire, des zones de périmètre et des pare-feu internes de votre conception.

Posez-vous les questions suivantes pour identifier les problèmes potentiels de déploiement et d'infrastructure :

  • Le réseau apporte-t-il une communication sécurisée ?

  • Votre topologie de déploiement inclut-elle un pare-feu interne ?

  • Votre topologie de déploiement inclut-elle un serveur d'applications distant ?

  • Quelles sont les restrictions imposées par la sécurité de l'infrastructure ?

  • Avez-vous envisagé les problèmes liés aux batteries de serveurs Web ?

  • Quels sont les niveaux de confiance pris en charge par l'environnement cible ?

Le réseau apporte-t-il une communication sécurisée ?

Vos données sont plus vulnérables lors du transit entre un client et un serveur, ou entre deux serveurs. Quel doit être le niveau de confidentialité des données ? Êtes-vous légalement responsable des données du client ?

Si votre application est responsable de la gestion et de la transformation sécurisées des données avant leur transit, le réseau est responsable de l'intégrité et de la confidentialité des données lors de leur transmission. Utilisez un algorithme de cryptage approprié lorsque les données doivent rester privées. De plus, assurez-vous que vos périphériques réseau sont sécurisés car ils gèrent l'intégrité du réseau.

Votre topologie de déploiement inclut-elle un pare-feu interne ?

Si un pare-feu interne sépare votre serveur Web d'un serveur d'applications ou d'un serveur de base de données, posez-vous les questions suivantes pour vous assurer que votre conception s'y conforme :

  • De quelle manière les serveurs situés en aval authentifient-ils le serveur Web ?

    Si vous utilisez des comptes de domaine et l'authentification Windows, le pare-feu ouvre-t-il les ports nécessaires ? Si ce n'est pas le cas, ou si le serveur Web et le serveur situé en aval se trouvent dans des domaines séparés, vous pouvez utiliser des comptes locaux en miroir. Par exemple, vous pouvez dupliquer le compte ASPNET local avec le minimum de privilèges utilisés pour exécuter l'application Web sur le serveur de base de données.

  • Utilisez-vous des transactions distribuées ?

    Si le serveur Web initie des transactions distribuées utilisant les services du Coordinateur de transactions distribuées (DTC) de Microsoft, le pare-feu interne ouvre-t-il les ports nécessaires pour la communication DTC ?

    Pour plus d'informations sur l'utilisation d'un DTC à travers un pare-feu, consultez l'article 250367 de la base de connaissances de Microsoft, intitulé « INFO: Configuring Microsoft Distributed Transaction Coordinator (DTC) to Work Through a Firewall » à l'adresse :
    http://support.microsoft.com/kb/250367.

Votre topologie de déploiement inclut-elle un serveur d'applications distant ?

Si votre topologie de déploiement inclut une couche intermédiaire physiquement distante, posez-vous les questions suivantes :

  • Utilisez-vous des services d'entreprise ?
    Si c'est le cas, avez-vous limité la plage des ports DCOM et un pare-feu interne peut-il les ouvrir ?

    Remarque dans certains scénarios, l'utilisation d'un service Web de couche intermédiaire comme frontal de l'application de services d'entreprise est le meilleur choix de conception. Avec une telle approche, le serveur Web peut communiquer avec le serveur d'applications par le port 80 en utilisant le protocole SOAP (Simple Object Access Protocol).

    Pour plus d'informations, reportez-vous aux articles suivants de la base de connaissances de Microsoft :

  • Utilisez-vous .NET Remoting ?
    Remoting a été conçu pour l'utilisation dans les scénarios de serveurs sécurisés. Le réseau prend-il en charge une stratégie IPSec garantissant que vos composants Remoting de la couche intermédiaire ne sont accessibles qu'à partir du serveur Web ? ASP.NET héberge-t-il vos composants distants avec la prise en charge de l'authentification et de l'autorisation ?

  • Utilisez-vous des services Web ?
    Si c'est le cas, de quelle manière les services Web de la couche intermédiaire authentifient-ils l'application Web ? L'application Web configure-t-elle les données d'identification sur le proxy du service Web afin que ce dernier puisse authentifier le serveur Web ? Dans le cas contraire, comment le service Web identifie-t-il l'appelant ?

Quelles sont les restrictions imposées par la sécurité de l'infrastructure ?

Votre conception émet-elle des hypothèses que les restrictions de sécurité de l'infrastructure hôte vont invalider ? Par exemple, les restrictions de sécurité peuvent nécessiter des compromis de conception basés sur la disponibilité des services requis, des protocoles ou des privilèges de compte. Posez-vous les questions suivantes :

  • Vous basez-vous sur des services ou des protocoles qui risquent de ne pas être disponibles ?
    Les services et les protocoles disponibles dans les environnements de développement et de test risquent de ne pas l'être dans les environnements de production. Communiquez avec l'équipe responsable de la sécurité de l'infrastructure pour bien comprendre les restrictions et les besoins.

  • Vous basez-vous sur des privilèges de comptes sensibles ?
    Votre conception doit utiliser des comptes de processus et de service et d'utilisateur les moins privilégiés. Effectuez-vous des opérations nécessitant des privilèges sensibles qui pourraient ne pas être autorisés ?

    Par exemple, votre application doit-elle créer des jetons d'emprunt d'identité de niveau thread pour créer des identités de service pour l'accès aux ressources ? Ceci nécessite le privilège « Agir comme partie du système d'exploitation », qui ne doit pas être accordé aux processus du serveur Web du fait du risque de sécurité accru associé à l'altération d'un processus. Si cette fonction est nécessaire, votre conception doit compartimenter les privilèges les plus élevés, par exemple dans une application de services d'entreprise hors processus.

Avez-vous envisagé les problèmes liés aux batteries de serveurs Web ?

Si votre application doit être déployée dans une batterie de serveurs Web, vous ne pouvez pas émettre d'hypothèses quant au serveur qui traitera les demandes des clients. Les demandes successives d'un même client peuvent être traitées par des serveurs distincts. Il en résulte que vous devez étudier les problèmes suivants :

  • Comment gérez-vous l'état de la session ?
    Dans une batterie de serveurs Web, vous ne pouvez pas gérer l'état de la session sur le serveur Web. Votre conception doit intégrer un emplacement de stockage de l'état sur un serveur, accessible par tous les serveurs Web de la batterie. Pour plus d'informations, reportez-vous à « Gestion de la session », plus loin dans ce module.

  • Utilisez-vous des clés de cryptage spécifiques à l'ordinateur ?
    Si vous envisagez d'utiliser le cryptage pour crypter les données d'une source de données partagée, telle qu'une base de données, les clés de cryptage et de décryptage doivent être identiques pour tous les serveurs de la batterie. Vérifiez que votre conception ne nécessite pas de mécanismes de cryptage exigeant une affinité entre les machines.

  • Utilisez-vous l'authentification des formulaires ou l'état d'affichage protégé ?
    Dans ce cas, vous dépendez des paramètres <clé machine>. Dans une batterie de serveurs Web, vous devez utiliser des clés communes à tous les serveurs.

  • Utilisez-vous Secure Sockets Layer (SSL) ?
    Si vous utilisez SSL pour crypter le trafic entre le navigateur et le serveur Web, où terminez-vous la connexion SSL ? Vos options incluent le serveur Web, un serveur Web doté d'une carte d'accélération, ou un équilibreur de charge doté d'une carte d'accélération. Terminer la session SSL sur un équilibreur de charge doté d'une carte d'accélération offre en général les meilleures performances, en particulier pour les sites présentant un grand nombre de connexions.

    Si vous terminez la session SSL sur un équilibreur de charge, le trafic réseau n'est pas crypté de l'équilibreur de charge au serveur Web. Cela signifie qu'un attaquant peut potentiellement détecter le trafic réseau après le décryptage des données, lorsqu'elles sont en transit entre l'équilibreur de charge et le serveur Web. Vous pouvez faire face à cette menace en vous assurant que l'environnement du serveur Web est physiquement sécurisé ou en utilisant le cryptage au niveau du transport offert par des stratégies IPSec pour protéger les liaisons du centre de données interne.

Quels sont les niveaux de confiance pris en charge par l'environnement cible ?

Le niveau de confiance de sécurité de l'accès au code de l'environnement cible détermine les ressources auxquelles votre code peut accéder et les opérations privilégiées qu'il peut exécuter. Vérifiez le niveau de confiance pris en charge par votre environnement cible. Si votre application Web est autorisée à fonctionner en confiance totale, votre code peut accéder à n'importe quelle ressource, en fonction de la sécurité du système d'exploitation.

Si votre application Web doit fonctionner avec un niveau de confiance réduit, ceci limite les types de ressources et les opérations privilégiées que votre code peut exécuter. Dans les scénarios à confiance partielle, votre conception doit mettre en sandbox votre code privilégié. Vous devez en outre utiliser des assemblys séparés pour isoler votre code privilégié. Ceci est fait pour que le code privilégié puisse être configuré séparément du reste de l'application et bénéficie des autorisations d'accès nécessaires au code.

Pour plus d'informations, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ».

Remarque les niveaux de confiance posent souvent problème si vous envisagez de déployer votre application sur un serveur partagé, ou si votre application doit être exécutée par une société d'hébergement. Dans ce cas, vérifiez la stratégie de sécurité et déterminez quels niveaux de confiance elle définit pour les applications Web.

Validation des entrées

Examinez comment votre application valide les entrées car les attaques contre les applications Web utilisent des entrées volontairement mal conformées. Injection SQL, scripts inter-site (XSS), dépassement de la capacité de la mémoire tampon, injection de code, et de nombreuses autres attaques de refus de service et par élévation des privilèges peuvent exploiter une validation médiocre des entrées. Le tableau 5.1 souligne les vulnérabilités de validation des entrées les plus courantes.

Tableau 5.1 : Vulnérabilités courantes de validation des entrées

Vulnérabilité

Implications

Entrées non validées dans le flux de données de sortie HTML (Hypertext Markup Language)

L'application est sensible aux attaques XSS.

Entrées non validées utilisées pour générer des requêtes SQL

L'application est sensible aux attaques d'injection SQL.

Dépendance vis-à-vis de la validation côté client

La validation côté client est facile à contourner.

Utilisation de noms de fichier d'entrée, d'URL, ou de noms d'utilisateurs pour des décisions de sécurité

L'application est sensible aux bogues des noms canoniques, qui se traduisent par des failles de sécurité.

Filtres d'application seule pour les entrées malveillantes

Ceci est presque impossible à réaliser correctement du fait de l'extrême diversité des entrées potentiellement malveillantes. L'application doit contraindre, rejeter et assainir les entrées.

Posez-vous les questions suivantes pour identifier les problèmes potentiels liés à la sécurité de la validation des entrées :

  • Comment validez-vous les entrées ?

  • Que faites-vous des entrées ?

Comment validez-vous les entrées ?

Quelle est l'approche de validation des entrées définie par votre conception ? En premier lieu, votre conception doit exposer la stratégie. Votre application doit contraindre, rejeter et assainir toute les entrées qu'elle reçoit. Contraindre les entrées est la meilleure approche car il est plus simple de valider des types, modèles et plages valides connus que de valider des données en recherchant des caractères connus comme étant incorrects. Pour une stratégie de défense renforcée, vous pouvez également rejeter les entrées connues comme étant incorrectes, puis assainir les entrées.

Les questions suivantes peuvent vous aider à identifier les vulnérabilités potentielles :

  • Connaissez-vous vos points d'entrée ?
    Vérifiez que la conception identifie les points d'entrée de l'application afin que vous puissiez suivre ce qu'il arrive aux champs de saisie individuels. Prenez en considération la saisie dans les pages Web, la saisie dans les composants et les services Web, et les entrées à partir des bases de données.

  • Connaissez-vous vos limites sécurisées ?
    La validation des entrées n'est pas toujours nécessaire si celles-ci sont transmises à partir d'une source de confiance située à l'intérieur de votre limite sécurisée, mais elle doit devenir obligatoire si les entrées proviennent de sources non fiables.

  • Comment validez-vous la saisie dans les pages Web ?
    Ne considérez pas l'utilisateur final comme une source de données fiable. Vérifiez que vous validez les champs de formulaires réguliers et masqués, les chaînes de requête et les cookies.

  • Validez-vous les arguments transmis à vos composants ou services Web ?
    Le seul cas dans lequel il peut être bon de ne pas le faire est lorsque les données sont reçues de l'intérieur de la limite sécurisée. En revanche, dans une stratégie de défense renforcée, plusieurs couches de validation sont recommandées.

  • Validez-vous les données récupérées à partir d'une base de données ?
    Vous devez également valider cette forme d'entrée, en particulier si d'autres applications écrivent dans la base de données. N'émettez aucune hypothèse quant au caractère complet ou non de la validation des entrées de l'autre application.

  • Centralisez-vous votre approche ?
    Pour les types courants de champs de saisie, examinez si vous utilisez des bibliothèques communes de validation et de filtrage pour vous assurer que les règles de validation sont respectées en permanence.

  • Vous basez-vous sur la validation côté client ?
    Ne le faites pas. La validation côté client peut aider à réduire le nombre de boucles vers le serveur mais ne vous y fiez pas pour la sécurité car elle est facile à contourner. Validez toutes les entrées au niveau du serveur.

Que faites-vous des entrées ?

Vérifiez ce que votre application fait de ses entrées car différents types de traitements peuvent se traduire par différents types de vulnérabilités. Par exemple, si vous utilisez les entrées dans les requêtes SQL, votre application est potentiellement vulnérable à l'injection SQL.

Posez-vous les questions suivantes pour vous aider à identifier les vulnérabilités potentielles :

  • Votre application est-elle sensible aux problèmes de noms canoniques ?
    Vérifiez si votre application utilise des noms basés sur les entrées pour prendre des décisions de sécurité. Par exemple, accepte-t-elle les noms d'utilisateur, noms de fichiers ou URL ? Il s'agit là de problèmes de noms canoniques bien connus du fait des nombreuses manières de représenter les noms. Si votre application accepte les noms en entrée, vérifiez s'ils sont validés et convertis en leur représentation canonique avant le traitement.

  • Votre application est-elle sensible aux attaques d'injection SQL ?
    Soyez extrêmement attentif à tout champ de saisie que vous utilisez pour former une requête SQL adressée à la base de données. Vérifiez la validation du type, de la longueur, du format et de la plage de ces champs. Vérifiez également le mode de génération des requêtes. Si vous utilisez des procédures stockées avec des paramètres, les paramètres d'entrée sont traités comme des littéraux et non comme du code exécutable. Ceci est une réduction efficace du risque.

  • Votre application est-elle sensible aux attaques XSS ?
    Si vous incluez des champs d'entrée au flux des données de sortie HTML, vous risquez d'être vulnérable à XSS. Vérifiez que les entrées sont validées et que les données de sortie sont codées. Soyez extrêmement attentif au mode de traitement des champs de saisie qui acceptent une plage de caractères HTML.

Authentification

Examinez de quelle manière votre application authentifie ses appelants, à quel endroit elle utilise l'authentification, et comment elle s'assure que les informations d'identification restent sécurisées lorsqu'elles sont stockées et lorsqu'elles sont transmises sur le réseau. Les vulnérabilités d'authentification peuvent rendre votre application sensible aux attaques par usurpation, attaques de dictionnaire, détournement de session, et aux autres attaques. Le tableau 5.2 souligne les vulnérabilités d'authentification les plus courantes.

Tableau 5.2 : Vulnérabilités d'authentification courantes

Vulnérabilité

Implications

Mots de passe peu sûrs

Le risque de décodage de mot de passe et d'attaques de dictionnaire s'accroît.

Texte des informations d'identification en clair dans les fichiers de configuration

Les personnes internes qui peuvent accéder au serveur ou les attaquants qui exploitent une vulnérabilité de l'hôte pour télécharger le fichier de configuration ont l'accès immédiat aux informations d'identification.

Transmission du texte des informations d'identification en clair sur le réseau

Les attaquants peuvent surveiller le réseau pour dérober les informations d'authentification et usurper l'identité.

Comptes sur-privilégiés

Les risques associés à une altération de processus ou de compte augmentent.

Sessions longues

Les risques associés au détournement de session augmentent.

Mélange de personnalisation et d'authentification

Les données de personnalisation sont adaptées aux cookies persistants. Les cookies d'authentification ne doivent pas être persistants.

Posez-vous les questions suivantes pour identifier les vulnérabilités potentielles liées à l'authentification effectuée par votre application :

  • Séparez-vous les zones publiques et restreintes ?

  • Avez-vous identifié les critères de compte de service ?

  • Comment authentifiez-vous l'appelant ?

  • Comment vous authentifiez-vous auprès de la base de données ?

  • Comment imposez-vous des pratiques renforcées de gestion des comptes ?

Séparez-vous les accès publics et restreints ?

Si votre application offre des zones publiques qui ne nécessitent pas l'authentification et des zones restreintes qui l'exigent, examinez de quelle manière la conception de votre site distingue les deux. Il est recommandé d'utiliser des sous-dossiers distincts pour les pages et les ressources restreintes et de les sécuriser dans Internet Information Services (IIS) en les configurant pour qu'ils requièrent l'utilisation de SSL. Cette approche vous permet de sécuriser les données sensibles et les cookies d'authentification en n'utilisant SSL que dans les zones de votre site qui l'exigent. Vous évitez ainsi les pertes de performances associées à l'utilisation de SSL sur l'ensemble du site.

Avez-vous identifié les critères de compte de service ?

Votre conception doit identifier la plage des comptes de service requise pour la connexion aux différentes ressources, notamment les bases de données, services d'annuaires et autres types de ressources réseau distantes. Assurez-vous que la conception n'exige pas un compte unique à privilèges élevés disposant des privilèges suffisants pour se connecter à la plage des différents types de ressources.

  • La conception exige-t-elle des comptes avec le minimum de privilèges ?
    Avez-vous identifié quelles ressources et opérations exigent quels privilèges ? Vérifiez que la conception identifie de façon précise quels privilèges chaque compte exige pour exécuter sa fonction particulière et utilisez des comptes avec le minimum de privilèges dans tous les cas.

  • L'application nécessite-t-elle la gestion des informations d'identification des comptes de service ?
    Si c'est le cas, vérifiez que les informations d'identification sont cryptées et conservées dans un emplacement restreint, tel qu'une clé de registre avec une liste de contrôle d'accès (ACL) restreinte.

Comment authentifiez-vous l'appelant ?

Examinez les aspects suivants concernant l'authentification d'un appelant. Les aspects que vous utilisez dépendent du type d'authentification utilisé par votre conception.

  • Transmettez-vous le texte des informations d'identification en clair sur le réseau ?
    Si vous utilisez l'authentification des formulaires ou l'authentification de base, ou si vous utilisez des services Web et transmettez des informations d'identification dans des en-têtes SOAP, veillez à utiliser SSL pour protéger les informations d'identification en transit.

  • Mettez-vous en œuvre votre propre magasin d'utilisateurs ?
    Si c'est le cas, vérifiez où et comment les informations d'identification de l'utilisateur seront stockées. Une erreur courante consiste à stocker des mots de passe en texte clair ou cryptés dans le magasin d'utilisateurs. Au lieu de cela, il est préférable de stocker un hachage du mot de passe pour vérification.

    Si vous validez des informations d'identification par rapport à un magasin d'utilisateurs du serveur SQL, soyez extrêmement attentif aux noms d'utilisateurs et mots de passe saisis. Vérifiez l'injection malveillante de caractères SQL.

  • Utilisez-vous l'authentification des formulaires ?
    Si oui, outre l'utilisation de SSL pour protéger les informations d'identification, il est recommandé d'utiliser SSL pour protéger le cookie d'authentification. Vérifiez en outre que votre conception utilise une durée de vie de session limitée pour contrer la menace d'attaques de relecture de cookie et vérifiez que le cookie est crypté.

    Pour plus d'informations sur l'authentification des formulaires, consultez le module 10, « Création de pages et de contrôles ASP.NET sécurisés » et le module 19, « Sécurisation de votre application ASP.NET et de vos services Web ».

Comment vous authentifiez-vous auprès de la base de données ?

Lorsque votre application se connecte à la base de données, étudiez le mécanisme d'authentification que vous utiliserez, quels comptes vous envisagez d'utiliser, et comment vous envisagez d'autoriser l'application dans la base de données.

Posez-vous les questions suivantes pour examiner votre approche vis-à-vis de l'authentification de la base de données :

  • Utilisez-vous l'authentification SQL ?
    Idéalement, votre conception utilise l'authentification Windows pour se connecter au serveur SQL car cette approche est intrinsèquement plus sûre. Si vous utilisez l'authentification SQL, examinez de quelle manière vous envisagez de sécuriser les informations d'identification sur le réseau et dans les chaînes de connexion à la base de données.

    Si votre infrastructure réseau ne fournit pas de canaux IPSec cryptés, vérifiez qu'un certificat de serveur est installé sur la base de données pour fournir le cryptage automatique des informations d'identification SQL. Examinez également comment vous envisagez de sécuriser les chaînes de connexion à la base de données car ces chaînes contiennent des noms d'utilisateur et des mots de passe de compte SQL.

  • Utilisez-vous le compte de processus ?
    Si vous utilisez le compte de processus de l'application et vous connectez au serveur SQL en utilisant l'authentification Windows, vérifiez que votre conception suppose l'utilisation du compte le moins privilégié possible. Le compte ASPNET local est fourni à cette fin, bien qu'avec les comptes locaux, vous deviez créer un compte en double sur le serveur de base de données.

    Si vous envisagez d'utiliser un compte de domaine, vérifiez qu'il s'agit d'un compte le moins privilégié et vérifiez que tous les pare-feu intermédiaires prennent en charge l'authentification Windows en ouvrant les ports concernés.

  • Utilisez-vous des comptes de service ?
    Si votre conception nécessite plusieurs identités pour prendre en charge une autorisation plus fine dans la base de données, examinez comment vous envisagez de stocker les informations d'identification du compte (dans l'idéal, elles sont cryptées en utilisant une API de protection des données (DPAPI) et conservées dans une clé de registre sécurisée) et comment vous envisagez d'utiliser l'identité de service.

    Examinez également quel processus sera utilisé pour créer le contexte de sécurité d'emprunt utilisant le compte de service. Ceci ne doit pas s'effectuer par le processus d'application ASP.NET sur Microsoft Windows 2000 car cela vous oblige à accroître les privilèges du compte de processus et à accorder le privilège « Agir comme partie du système d'exploitation ». Cette solution doit être évitée car elle augmente le facteur de risque de façon significative.

  • Avez-vous envisagé d'utiliser l'identité d'utilisateur Internet anonyme ?
    Pour les applications utilisant l'authentification de formulaires ou par passeport, vous pouvez configurer un compte utilisateur anonyme distinct pour chaque application. Ensuite, vous pouvez activer l'emprunt d'identité et utiliser l'identité anonyme pour accéder à la base de données. Cette approche permet le suivi séparé de l'autorisation et de l'identité pour des applications distinctes du même serveur Web.

  • Utilisez-vous l'identité de l'utilisateur d'origine ?
    Si votre conception nécessite l'emprunt d'identité de l'appelant d'origine, vous devez déterminer si cette approche offre une évolutivité suffisante, puisque le regroupement de connexions est impossible. Une autre approche consiste à faire circuler l'identité de l'appelant d'origine au niveau de l'application par l'intermédiaire de paramètres de requête sécurisés.

  • Comment stockez-vous les chaînes de connexion à la base de données ?
    Si des chaînes de connexion à la base de données sont préprogrammées ou stockées en clair dans des fichiers de configuration ou dans le catalogue COM+, cela les rend vulnérables. Il est préférable de crypter les chaînes de connexion et de limiter l'accès aux données cryptées.

    Pour plus d'informations sur les différentes options de connexion au serveur SQL et sur le stockage des chaînes de connexion à la base de données, consultez le module 14, « Création d'un accès sécurisé aux données ».

Comment imposez-vous des pratiques renforcées de gestion des comptes ?

L'utilisation de mots de passe fiables, des tentatives de connexion limitées, et d'autres pratiques renforcées de gestion des comptes peut être imposée par la stratégie de sécurité de Windows si votre application utilise l'authentification Windows. Sinon, la couche application en est responsable. Examinez les aspects suivants concernant la gestion des comptes de votre application :

  • Votre application impose-t-elle des mots de passe renforcés ?
    Par exemple, vos pages Web ASP.NET utilisent-elles des expressions régulières pour vérifier les règles de complexité des mots de passe ?

  • Limitez-vous le nombre de tentatives de connexion ayant échoué ?
    Ceci peut aider à contrer les attaques de dictionnaire.

  • Révélez-vous un trop grand nombre d'informations en cas de panne ?
    Veillez à ne pas afficher de messages tels que « Mot de passe incorrect » car ceci indique aux utilisateurs malveillants que le nom d'utilisateur est correct. Ceci leur permet de concentrer leurs efforts sur le décodage des mots de passe.

  • Imposez-vous le changement périodique des mots de passe ?
    Ceci est recommandé car il existe, dans le cas contraire, une forte probabilité que l'utilisateur ne change pas son mot de passe, ce qui le rend encore plus vulnérable.

  • Pouvez-vous rapidement désactiver des comptes en cas d'altération ?
    Si un compte a été détourné, pouvez-vous facilement le désactiver pour empêcher l'attaquant de continuer à l'utiliser ?

  • Votre application enregistre-t-elle les tentatives de connexion ?
    L'enregistrement des tentatives infructueuses de connexion aide à détecter un attaquant qui tente une intrusion.

Autorisation

Examinez de quelle manière votre application prend en charge l'autorisation des utilisateurs. Examinez également de quelle manière sont définies les autorisations de votre application dans la base de données et comment s'effectue le contrôle d'accès aux ressources système. Les vulnérabilités d'autorisation peuvent se traduire par la divulgation d'informations, la falsification des données et l'élévation des privilèges. La stratégie de défense renforcée est le principe de sécurité clé à appliquer à la stratégie d'autorisation de votre application. Le tableau 5.3 souligne les vulnérabilités d'autorisation les plus courantes.

Tableau 5.3 : Vulnérabilités courantes d'autorisation

Vulnérabilité

Implications

Dépendance vis-à-vis d'un garde-barrière unique

Si le garde-barrière est contourné ou mal configuré, un utilisateur peut obtenir un accès non autorisé.

Absence de verrouillage des ressources système contre les identités d'application

Un attaquant peut contraindre l'application à accéder aux ressources système à accès restreint.

Absence de limitation d'accès à la base de données des procédures stockées spécifiées

Un attaquant lance une attaque d'injection SQL pour récupérer, manipuler ou détruire les données.

Séparation inadéquate des privilèges

Il n'existe aucun suivi des comptes ou possibilité d'effectuer une autorisation utilisateur par utilisateur.

Posez-vous les questions suivantes pour valider la stratégie d'autorisation de la conception de votre application :

  • Comment définissez-vous les autorisations pour les utilisateurs finaux ?

  • Comment définissez-vous les autorisations de l'application dans la base de données ?

  • Comment restreignez-vous l'accès aux ressources de niveau système ?

Comment définissez-vous les autorisations pour les utilisateurs finaux ?

Vous devez envisager l'autorisation selon deux perspectives lors de la conception. En premier lieu, envisagez l'autorisation des utilisateurs finaux. Quels utilisateurs sont autorisés à accéder à quelles ressources et à réaliser quelles opérations ? En second lieu, comment empêchez-vous les utilisateurs malveillants d'utiliser l'application pour accéder aux ressources de niveau système ? Posez-vous les questions suivantes pour valider la stratégie d'autorisation de la conception de votre application :

  • Utilisez-vous une stratégie de défense renforcée ?
    Vérifiez que votre conception n'est pas basée sur un garde-barrière unique pour imposer le contrôle d'accès. Envisagez ce qui se passe en cas d'échec du garde-barrière ou si une attaque réussit à le contourner.

  • Quels sont les gardes-barrière utilisés ?
    Les options incluent les autorisations IIS Web, les autorisations NTFS, l'autorisation d'accès au fichier ASP.NET (qui ne s'applique qu'avec l'authentification Windows), l'autorisation d'accès à l'URL, et les demandes d'autorisation principales. Si certains types ne sont pas utilisés, veiller à déterminer pourquoi.

  • Utilisez-vous une approche basée sur les rôles ?
    Si c'est le cas, comment les listes de rôles sont-elles gérées et comment les interfaces d'administration nécessaires sont-elles sécurisées ?

  • Vos rôles offrent-ils la séparation adéquate des privilèges ?
    Votre conception offre-t-elle suffisamment de précision pour séparer correctement les privilèges associés aux différents rôles d'utilisateurs ? Évitez les situations dans lesquelles les rôles se voient accorder des privilèges élevés uniquement pour satisfaire les besoins de certains utilisateurs. Envisagez plutôt d'ajouter de nouveaux rôles.

Comment définissez-vous les autorisations de l'application dans la base de données ?

Les comptes utilisés par votre application pour se connecter à la base de données doivent avoir des capacités restreintes, suffisantes pour les besoins de l'application, mais sans plus.

  • L'application accède-t-elle à la base de données en utilisant des procédures stockées ?
    Ceci est recommandé car le nom de connexion de l'application ne peut recevoir d'autorisation que pour accéder aux procédures stockées spécifiées. Ce nom de connexion peut être restreint pour ne pas effectuer d'opérations directes de création/lecture/mise à jour/suppression (CRUD) sur la base de données.

    Ceci bénéficie à la sécurité, aux performances et à la facilité de gestion future. Pour plus d'informations concernant les approches en matière d'autorisation sur la base de données, consultez le module 14, « Création d'un accès sécurisé aux données ».

Comment restreignez-vous l'accès aux ressources de niveau système ?

Lorsque vous concevez votre application, envisagez les restrictions de l'application en termes d'accès aux ressources de niveau système. L'application ne doit pouvoir accéder qu'aux ressources minimales requises. Ceci constitue une stratégie d'atténuation du risque qui limite les dommages en cas d'altération de l'application. Posez-vous les questions suivantes :

  • Votre conception utilise-t-elle la sécurité d'accès au code ?
    La sécurité d'accès au code offre un modèle de contrainte de ressource qui peut empêcher le code (et les applications Web) d'accéder à certains types de ressources de niveau système. Lorsque vous utilisez la sécurité d'accès au code, elle influence inévitablement votre conception. Déterminez si vous souhaitez inclure la sécurité d'accès au code dans vos plans de conception, puis effectuez la conception en conséquence, en isolant et en mettant en sandbox le code privilégié et en plaçant le code d'accès aux ressources dans ses propres assemblys.

  • Qu'est-ce qui identifie ce que fait l'application ?
    Votre conception doit identifier toutes les identités utilisées par l'application, y compris l'identité de processus et toutes les identités d'emprunt, notamment les comptes d'utilisateurs Internet anonymes et les identités de service. La conception doit également indiquer à quelles ressources ces identités ont besoin d'accéder.

    Lors de la phase de déploiement, les ACL appropriées peuvent être configurées sur les ressources de niveau système pour garantir que les identités de l'application n'ont accès qu'aux ressources dont elles ont besoin.

    Pour plus d'informations concernant la conception de la sécurité de l'accès au code, reportez-vous au module 9, « Utilisation de la sécurité d'accès au code avec ASP.NET ».

Gestion de la configuration

Si votre application offre une interface d'administration qui lui permet d'être configurée, examinez comment les interfaces d'administration sont sécurisées. Examinez également comment les données de configuration sensibles sont sécurisées. Le tableau 5.4 illustre les vulnérabilités de gestion de configuration les plus courantes.

Tableau 5.4 : Vulnérabilités de gestion de configuration courantes

Vulnérabilité

Implications

Interfaces d'administration
non sécurisées

Les utilisateurs non autorisés peuvent reconfigurer votre application
et accéder aux données sensibles.

Configurations stockées non sécurisées

Les utilisateurs non autorisés peuvent accéder
aux configurations stockées et obtenir des secrets tels que les noms et les mots de passe des comptes, et les
informations de connexion à la base de données.

Données de configuration en clair

N'importe qui pouvant se connecter au serveur peut consulter les
données de configuration sensibles.

Trop d'administrateurs

Ceci rend difficile l'analyse et l'enquête approfondie sur les administrateurs.

Comptes de processus sur-privilégiés et
comptes de service

Ceci peut favoriser les attaques basées sur l'élévation des privilèges.

Posez-vous les questions suivantes pour valider la stratégie de conception de votre application en matière de gestion de la configuration :

  • Prenez-vous en charge l'administration à distance ?

  • Sécurisez-vous les configurations stockées ?

  • Séparez-vous les privilèges d'administration ?

Prenez-vous en charge l'administration à distance ?

Si votre conception spécifie l'administration à distance, vous devez sécuriser les interfaces d'administration et les configurations stockées du fait de la nature sensible des opérations et des données accessibles par l'interface d'administration. Examinez les aspects suivants concernant la conception de votre administration à distance :

  • Utilisez-vous l'authentification renforcée ?
    Tous les utilisateurs de l'interface d'administration doivent être invités à s'authentifier. Utilisez l'authentification renforcée, telle que l'authentification Windows ou l'authentification client-certificat.

  • Cryptez-vous le trafic réseau ?
    Utilisez des canaux de communication cryptés, tels que ceux fournis par les connexions IPSec ou de type réseau privé virtuel (VPN). Ne prenez pas en charge l'administration distante sur des canaux non sécurisés. IPSec vous permet de limiter l'identité et le nombre de machines clientes pouvant être utilisées pour administrer le serveur.

Sécurisez-vous les configurations stockées ?

Identifiez les configurations stockées de votre application et examinez votre approche en matière de restriction d'accès aux magasins et de sécurisation des données à l'intérieur de ces magasins.

  • Votre magasin de configurations se trouve-t-il dans l'espace Web ?
    Les données de configuration conservées dans les fichiers de l'espace Web sont considérées comme étant moins sécurisées que celles conservées hors de l'espace Web. Les erreurs de configuration d'hôte ou les bogues inconnus peuvent permettre à un attaquant de récupérer et de télécharger des fichiers de configuration sur HTTP.

  • Les données du magasin de configurations sont-elles sécurisées ?
    Assurez-vous que les principaux éléments des données de configuration, tels que les chaînes de connexion à la base de données, les clés de cryptage et les informations d'identification de compte de service, sont cryptés à l'intérieur du magasin.

  • Comment l'accès au magasin de configurations est-il restreint ?
    Vérifiez que l'interface d'administration offre l'autorisation nécessaire pour assurer que seuls les administrateurs authentifiés peuvent accéder aux données et les manipuler.

Séparez-vous les privilèges d'administration ?

Si vos interfaces d'administration prennent en charge des fonctionnalités différentes - par exemple les mises à jour de contenu du site, la reconfiguration des comptes de service et les informations de connexion à la base de données - vérifiez que vos interfaces d'administration prennent en charge l'autorisation basée sur les rôles pour distinguer entre les développeurs de contenu et les opérateurs ou les administrateurs système. Par exemple, la personne responsable de la mise à jour du contenu statique d'un site Web ne doit pas nécessairement être autorisée à modifier la limite de crédit d'un client ou à reconfigurer une chaîne de connexion à la base de données.

Données sensibles

Examinez de quelle manière votre application gère les données sensibles dans le magasin, dans la mémoire de l'application et en transit sur le réseau. Le tableau 5.5 illustre les vulnérabilités les plus courantes associées à la gestion des données sensibles.

Tableau 5.5 : Vulnérabilités courantes associées à la gestion des données sensibles

Vulnérabilité

Implications

Stockage de secrets lorsque ce n'est pas nécessaire

Ceci augmente considérablement le risque de sécurité par rapport au non-stockage du secret.

Stockage des secrets dans le code

Si le code se trouve sur le serveur, un attaquant peut se trouver en mesure de le télécharger. Les secrets sont visibles dans les assemblys binaires.

Stockage des secrets en clair

N'importe qui pouvant se connecter au serveur peut consulter les données secrètes.

Transmission de données sensibles en clair sur des réseaux

Des écoutes clandestines peuvent surveiller le réseau pour révéler et falsifier les données.

Posez-vous les questions suivantes pour valider la gestion des données sensibles par votre application :

  • Stockez-vous des secrets ?

  • Comment stockez-vous les données sensibles ?

  • Transmettez-vous des données sensibles sur le réseau ?

  • Consignez-vous des données sensibles ?

Stockez-vous des secrets ?

Les secrets incluent les données de configuration de l'application, tels que les mots de passe des comptes et les clés de cryptage. Si possible, identifiez d'autres approches de conception qui suppriment toute raison de stocker des secrets. Si vous gérez des secrets, laissez la plate-forme les gérer afin de soulager votre application autant que possible. Si vous stockez des secrets, posez-vous les questions suivantes :

  • Pouvez-vous éviter de stocker des secrets ?
    Si vous utilisez une autre technique d'implémentation, il est possible qu'elle vous évite de stocker des secrets. Par exemple, si vous devez uniquement vérifier si un utilisateur connaît un mot de passe, vous n'avez pas besoin de stoker des mots de passe. Stockez plutôt des hachages de mot de passe.

    En outre, si vous utilisez l'authentification Windows, vous évitez de stocker des chaînes de connexion qui intègrent des informations d'identification.

  • Comment stockez-vous les secrets ?
    Si vous utilisez le cryptage, comment sécurisez-vous les clés de cryptage ? Envisagez l'utilisation du cryptage DPAPI fourni par la plate-forme, qui se charge à votre place de la gestion des clés.

  • Où stockez-vous les secrets ?
    Examinez de quelle manière votre application stocke ses données cryptées. Pour une sécurité maximale, l'accès aux données cryptées doit être restreint aux ACL Windows. Vérifiez que l'application ne stocke pas de secrets en clair ou dans le code source.

    Si vous utilisez l'autorité de sécurité locale, le code qui récupère le secret doit s'exécuter avec des privilèges d'administrateur, ce qui augmente le risque. Une autre approche ne nécessitant pas de privilèges étendus consiste à utiliser DPAPI.

  • Comment traitez-vous les secrets ?
    Examinez comment votre application accède aux secrets et la durée pendant laquelle ils demeurent en clair dans la mémoire. Les secrets doivent généralement être récupérés à la demande, utilisés pendant la durée la plus réduite possible, puis supprimés.

  • Stockez-vous des secrets dans des cookies ?
    Si c'est le cas, assurez-vous que le cookie est crypté et ne demeure pas sur l'ordinateur client.

Comment stockez-vous les données sensibles ?

Si vous stockez des données d'application sensibles, telles que les informations de cartes de crédit, examinez comment les protéger.

  • Quel algorithme de cryptage utilisez-vous ? Vous devez crypter les données en utilisant un algorithme de cryptage renforcé avec taille de clé élevée, telle que Triple DES.

  • Comment sécurisez-vous vos clés de cryptage ? La sécurité des données est directement liée à la clé de cryptage, c'est la raison pour laquelle vous devez étudier comment sécuriser cette clé. Dans l'idéal, il est recommandé de crypter la clé à l'aide de DPAPI et de la sécuriser dans un emplacement restreint, par exemple dans une clé de registre.

Transmettez-vous des données sensibles sur le réseau ?

Si vous transmettez des données sensibles sur le réseau, vérifiez qu'elles sont soit cryptées par l'application, soit uniquement transmises sur des liaisons de communication cryptées.

Consignez-vous des données sensibles ?

Examinez si votre application (ou l'hôte) consigne des données sensibles telles que des mots de passe de comptes utilisateurs dans des fichiers journaux en clair. Il est généralement recommandé de l'éviter. Assurez-vous que l'application ne transmet pas de données sensibles dans des chaînes de requête car celles-ci sont consignées et sont également clairement visibles dans la barre d'adresse du navigateur du client.

Gestion des sessions

Du fait que les applications Web sont construites sur le protocole HTTP sans état, la responsabilité de la gestion des sessions se situe au niveau de l'application. Examinez l'approche de la gestion des sessions par votre application car elle affecte directement la sécurité globale. Le tableau 5.6 illustre les vulnérabilités les plus courantes associées à la gestion des sessions.

Tableau 5.6 : Vulnérabilités courantes de gestion des sessions

Vulnérabilité

Implications

Transmission d'identificateurs de session sur des canaux non cryptés

Les attaquants peuvent capturer des identificateurs de session pour usurper des identités.

Durée de vie prolongée d'une session

Ceci augmente le risque de détournement de session et d'attaques par relecture.

Magasins d'états de session non sécurisés

Les attaquants peuvent accéder aux données de session privées d'un utilisateur.

Identificateurs de session dans des chaînes de requête

Les identificateurs de session sont aisément modifiables sur le client ; ils permettent alors d'usurper l'identité et d'accéder à l'application en se faisant passer pour un autre utilisateur.

Posez-vous les questions suivantes pour valider la gestion des données sensibles par votre application :

  • Comment les identificateurs de session sont-ils échangés ?

  • Limitez-vous la durée de vie des sessions ?

  • Comment le magasin d'états de session est-il sécurisé ?

Comment les identificateurs de session sont-ils échangés ?

Examinez l'identificateur de session utilisé par votre application pour gérer les sessions utilisateur et comment s'effectue l'échange de ces identificateurs de session. Posez-vous les questions suivantes :

  • Transmettez-vous des identificateurs de session sur des canaux non cryptés ?
    Si vous surveillez l'état des sessions à l'aide d'identificateurs de session - par exemple, des jetons contenus dans des cookies - examinez si l'identificateur ou le cookie n'est transmis que sur un canal crypté, tel que SSL.

  • Cryptez-vous les cookies des sessions ?
    Si vous utilisez l'authentification des formulaires, vérifiez que votre application crypte les cookies d'authentification en utilisant l'attribut protection=« All » de l'élément <formulaires>. Cette pratique est recommandée en plus de SSL pour atténuer le risque d'attaque XSS qui parviendrait à dérober le cookie d'authentification d'un utilisateur.

  • Transmettez-vous des identificateurs de session dans des chaînes de requête ?
    Assurez-vous que votre application ne transmet pas d'identificateurs de session dans des chaînes de requête. Ces chaînes sont aisément modifiables sur le client, ce qui pourrait permettre à un utilisateur d'accéder à l'application sous l'identité d'un autre, d'accéder aux données privées d'autres utilisateurs et potentiellement d'élever des privilèges.

Limitez-vous la durée de vie des sessions ?

Examinez la durée pendant laquelle votre application considère valide un identificateur de session. L'application doit limiter cette durée pour atténuer le risque d'attaque de détournement de session et par relecture.

Comment le magasin d'états de session est-il sécurisé ?

Examinez de quelle manière votre application stocke l'état des sessions. L'état des sessions peut être stocké dans le processus de l'application Web, le service d'état de session ASP.NET, ou un magasin d'états SQL Server. Si vous utilisez un magasin d'états distant, assurez-vous que la liaison du serveur Web au magasin distant est cryptée avec IPSec ou SSL pour protéger les données du réseau.

Pour plus d'informations sur la sécurisation de l'état de session ASP.NET, reportez-vous à la section « Etat de session » dans le module 19, « Sécurisation de votre application ASP.NET et de vos services Web ».

Cryptographie

Si votre application utilise la cryptographie à des fins de sécurité, examinez ce qu'elle utilise et comment. Le tableau 5.7 illustre les vulnérabilités les plus courantes associées à la cryptographie.

Tableau 5.7 : Vulnérabilités de cryptographie courantes

Vulnérabilité

Implications

Utilisation d'une cryptographie personnalisée

Il est presque certain qu'elle sera moins sécurisée que la cryptographie testée et éprouvée de la plate-forme.

Utilisation du mauvais algorithme ou d'une taille de clé trop petite

Les algorithmes plus récents augmentent la sécurité, de même que les tailles de clé plus élevées.

Absence de sécurisation des clés de cryptage

La sécurité des données cryptées est directement liée à la clé de cryptage.

Utilisation de la même clé pendant une longue durée

Une clé statique risque davantage d'être découverte à terme.

Posez-vous les questions suivantes pour valider la gestion des données sensibles par votre application :

  • Pourquoi utilisez-vous certains algorithmes ?

  • Comment sécurisez-vous vos clés de cryptage ?

Pourquoi utilisez-vous certains algorithmes ?

La cryptographie n'offre de réelle sécurité que si elle est utilisée de façon appropriée et si les algorithmes sont adaptés à la tâche correspondante. La robustesse de l'algorithme est également importante. Posez-vous les questions suivantes pour examiner votre utilisation des algorithmes de cryptographie :

  • Développez-vous votre propre cryptographie ?
    Ne le faites pas. Les algorithmes et les routines cryptographiques sont notoirement difficiles à développer si l'on cherche à obtenir de bons résultats. Les implémentations personnalisées se traduisent fréquemment par une protection médiocre et sont presque toujours moins sécurisées que les services éprouvés fournis par les plates-formes.

  • Utilisez-vous l'algorithme et la taille de clé corrects ?
    Examinez les algorithmes utilisés par votre application et à quelles fins. Les tailles de clé plus élevées se traduisent par une meilleure sécurité, mais c'est au détriment des performances. Le cryptage renforcé est des plus important pour les données persistantes conservées dans des magasins de données pendant de longues périodes.

Pour plus d'informations sur le choix d'un algorithme et d'une taille de clé appropriés, reportez-vous à la section Cryptographie du module 4, « Instructions de conception pour la sécurisation des applications Web ».

Comment sécurisez-vous vos clés de cryptage ?

La sécurité des données cryptées est directement liée à la clé. Pour déchiffrer des données cryptées, un attaquant doit être capable de récupérer la clé et le texte de cryptage. C'est pourquoi vous devez examiner votre conception pour vous assurer que les clés de cryptage sont sécurisées. Posez-vous les questions suivantes :

  • Comment sécurisez-vous votre clé de cryptage ?
    Si vous utilisez DPAPI, la plate-forme gère la clé pour vous. Sinon, l'application en est responsable. Examinez de quelle manière votre application sécurise ses clés de cryptage. Une bonne approche consiste à utiliser DPAPI pour crypter les clés de cryptage requises par d'autres formes de cryptage. Stockez ensuite la clé cryptée de façon sécurisée, par exemple en la plaçant dans le registre sous une clé configurée avec une liste de contrôle d'accès restreinte.

  • À quelle fréquence les clés sont-elles recyclées ?
    Ne faites une utilisation abusive des clés. Plus vous utilisez une clé longtemps, plus elle risque d'être découverte. Votre conception prend-elle en considération la manière et la fréquence avec lesquelles vous allez recycler les clés et comment elles seront distribuées et installées sur vos serveurs ?

Manipulation des paramètres

Examinez de quelle manière votre application utilise les paramètres. Ces paramètres incluent les champs de formulaire, les chaînes de requête, les cookies, les en-têtes HTTP et l'état d'affichage qui sont transmis entre le client et le serveur. Si vous transmettez des données sensibles, telles que des identificateurs de session, en utilisant des paramètres tels que des chaînes de requête, un client malveillant peut aisément contourner vos vérifications côté serveur avec une simple manipulation de paramètres. Le tableau 5.8 illustre les vulnérabilités de manipulation de paramètres les plus courantes.

Tableau 5.8 : Vulnérabilités de manipulation de paramètres courantes

Vulnérabilité

Implications

Absence de validation de tous les paramètres d'entrée

Votre application est sensible aux attaques par refus de service et d'injection de code, y compris l'injection SQL et XSS.

Données sensibles dans des cookies non cryptés

Les données des cookies peuvent être modifiées sur le client ou capturées et modifiées lors de leur transmission sur le réseau.

Données sensibles dans des chaînes de requête et des champs de formulaire

Ceci peut être aisément modifié sur le client.

Confiance dans les informations d'en-têtes HTTP

Ceci peut être aisément modifié sur le client.

État d'affichage non protégé

Ceci peut être aisément modifié sur le client.

Posez-vous les questions suivantes pour vous assurer que votre conception n'est pas sensible aux attaques par manipulation de paramètres :

  • Validez-vous tous les paramètres d'entrée ?

  • Transmettez-vous des données sensibles dans des paramètres ?

  • Utilisez-vous des données d'en-tête HTTP pour la sécurité ?

Validez-vous tous les paramètres d'entrée ?

Vérifiez que votre application valide tous les paramètres d'entrée, y compris les champs de formulaires réguliers et masqués, les chaînes de requête et les cookies.

Transmettez-vous des données sensibles dans des paramètres ?

Si votre application transmet des données sensibles dans des paramètres tels que des chaînes de requêtes ou des champs de formulaire, examinez la raison pour laquelle elle accorde la faveur à cette approche plutôt qu'à celle beaucoup plus sécurisée consistant à transmettre un identificateur de session (par exemple, dans un cookie crypté). Utilisez ces informations pour associer la session à l'état d'un utilisateur conservé dans le magasin d'états sur le serveur. Posez-vous les questions suivantes :

  • Cryptez-vous des cookies avec des données sensibles ?
    Si votre application utilise un cookie contenant des données sensibles, telles qu'un nom d'utilisateur ou une liste de rôles, assurez-vous qu'il est crypté.

  • Transmettez-vous des données sensibles dans des chaînes de requête ou des champs de formulaire ?
    Ceci n'est pas recommandé car il n'existe pas de moyen simple d'éviter la manipulation des données dans des chaînes de requête ou des champs de formulaire. Envisagez plutôt d'utiliser des identificateurs de session cryptés et de stocker les données sensibles dans le magasin d'états de session sur le serveur.

  • Protégez-vous l'état d'affichage ?
    Si vos pages Web ou vos contrôles utilisent l'état d'affichage pour conserver l'état sur les requêtes HTTP, vérifiez que l'état d'affichage est crypté et que son intégrité est vérifiée avec des codes d'authentification des messages (MACs). Vous pouvez configurer cette option au niveau de la machine ou page par page.

Utilisez-vous des données d'en-tête HTTP pour la sécurité ?

Assurez-vous que votre application Web ne prend pas de décisions de sécurité basées sur les informations des en-têtes HTTP car un attaquant peut aisément manipuler l'en-tête. Ne vous fiez pas à la valeur du champ « referer » HTTP pour vérifier que la requête émane d'une page générée par votre application Web - ceci crée des vulnérabilités. Ceci est intrinsèquement dangereux car le champ « referer » est aisément modifiable par le client.

Gestion des exceptions

Examinez la manière dont votre application gère les conditions d'erreur. Il est recommandé d'utiliser en permanence une gestion structurée des exceptions. Vérifiez également que votre application ne révèle pas trop d'informations lorsqu'une exception se produit. Le tableau 5.9 illustre les deux principales vulnérabilités de gestion des exceptions.

Tableau 5.9 : Vulnérabilités courantes de gestion des exceptions

Vulnérabilité

Implications

Absence d'utilisation d'une gestion structurée des exceptions

Votre application est plus sensible aux attaques par refus de service et aux failles logiques, ce qui peut se traduire par des failles de sécurité.

Révélation d'un trop grand nombre d'informations au client

Un attaquant peut utiliser ces informations pour préparer et régler de futures attaques.

Posez-vous les questions suivantes pour vous assurer que votre conception n'est pas sensible aux failles de sécurité liées à la gestion des exceptions :

  • Utilisez-vous une gestion structurée des exceptions ?

  • Révélez-vous un trop grand nombre d'informations au client ?

Utilisez-vous une gestion structurée des exceptions ?

Examinez de quelle manière votre application utilise la gestion structurée des exceptions. Votre conception doit prévoir une utilisation cohérente dans l'ensemble de l'application de la gestion structurée des exceptions. Ceci crée des applications plus robustes et votre application risque moins de rester dans des états instables pouvant se traduire par des failles de sécurité.

Révélez-vous un trop grand nombre d'informations au client ?

Vérifiez qu'un utilisateur malveillant ne peut pas exploiter des informations trop détaillées, contenues dans un message d'erreur. Posez-vous les questions suivantes :

  • Identifiez-vous, gérez-vous et consignez-vous les exceptions sur le serveur ?
    Vérifiez que l'application ne permet pas à des conditions d'exception internes de se propager au-delà de ses limites. Les exceptions doivent être identifiées et consignées sur le serveur et, le cas échéant, des messages d'erreur génériques doivent être retournés au client.

  • Utilisez-vous un système de gestion centralisée des exceptions ?
    Le meilleur moyen de gérer et de consigner des exceptions en permanence dans toute l'application consiste à utiliser un système de gestion formalisé des exceptions. Vous pouvez également lier ce système à des systèmes de surveillance utilisés par l'équipe en charge de l'exploitation pour surveiller le fonctionnement et les performances.

  • Avez-vous défini un ensemble de messages d'erreur personnalisés ?
    Votre conception doit définir les messages d'erreur personnalisés qu'utilisera votre application lorsque des erreurs critiques se présenteront. Assurez-vous qu'ils ne contiennent pas de données sensibles pouvant être exploitées par un utilisateur malveillant.

    Pour plus d'informations sur la conception et l'implémentation d'une infrastructure de gestion des exceptions pour les applications .NET, consultez l'article MSDN, « Exception Management Architecture Guide, à l'adresse: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/exceptdotnet.asp.

Audit et journalisation

Examinez de quelle manière votre application utilise l'audit et la journalisation. Outre la prévention des problèmes de répudiation, l'analyse régulière des fichiers journaux aide à identifier les signes d'intrusion. Le tableau 5.10 illustre les vulnérabilités d'audit et de journalisation les plus courantes.

Tableau 5.10 : Vulnérabilités courantes d'audit et de journalisation

Vulnérabilité

Implications

Absence d'audit des échecs de connexion

Les tentatives d'intrusion passent inaperçues.

Absence de sécurisation des fichiers d'audit

Un attaquant peut masquer ses traces.

Absence d'audit à travers les couches de l'application

La menace de répudiation augmente.

Posez-vous les questions suivantes pour vérifier l'approche d'audit et de journalisation de votre application :

  • Avez-vous identifié les principales activités à analyser ?

  • Avez-vous pris en considération la manière de faire circuler l'identité de l'appelant d'origine ?

  • Avez-vous pris en considération les stratégies de gestion des fichiers journaux ?

Avez-vous identifié les principales activités à analyser ?

Votre conception doit définir les activités qui doivent être analysées. Posez-vous les questions suivantes :

  • Effectuez-vous un audit des tentatives infructueuses de connexion ?
    Ceci vous permet de détecter les tentatives d'intrusion et de décodage des mots de passe.

  • Effectuez-vous un audit d'autres opérations clés ?
    Veillez à auditer les autres événements clés, notamment la récupération des données, les communications réseau et les fonctions d'administration (par exemple l'activation et la désactivation de la journalisation).

Avez-vous pris en considération la manière de faire circuler l'identité de l'appelant d'origine ?

Votre conception doit vérifier que l'audit de l'activité s'effectue sur les différents niveaux de l'application. Pour ce faire, l'identité de l'appelant d'origine doit être disponible à chaque niveau.

  • Effectuez-vous l'audit à travers les niveaux de l'application ?
    Examinez si chaque niveau assure comme il le devrait un audit de l'activité.

  • Comment synchronisez-vous plusieurs journaux ?
    Les fichiers journaux peuvent être nécessaires dans les procédures judiciaires pour apporter la preuve des délits perpétrés par des individus ou pour résoudre des cas de répudiation. En général, les audits qui font le plus autorité sont ceux générés au moment exact de l'accès à la ressource, par les routines chargées de cet accès. Vérifiez que la conception de l'application prend en compte la synchronisation des fichiers journaux et consigne une forme d'identificateur de requête pour s'assurer que les différentes entrées d'un fichier journal peuvent être corrélées et mises en rapport avec une requête unique.

  • Comment faites-vous circuler l'identité de l'appelant d'origine ?
    Si vous ne faites pas circuler l'identité de l'appelant d'origine au niveau du système d'exploitation, par exemple, du fait de l'évolutivité limitée de cette approche, identifiez comment l'application la fait circuler. Ceci est nécessaire pour l'audit inter-couche (et potentiellement pour l'autorisation).

    En outre, si plusieurs utilisateurs correspondent à un seul rôle de l'application, vérifiez que celle-ci consigne l'identité de l'appelant d'origine.

Avez-vous pris en considération les stratégies de gestion des fichiers journaux ?

Vérifiez si la conception de votre application prend en compte la manière de sauvegarder, d'archiver et d'analyser les fichiers journaux. Les fichiers journaux doivent être archivés régulièrement pour éviter toute saturation ou blocage dans un cycle, et ils doivent être régulièrement analysés pour détecter les signes d'intrusion. Vérifiez également que les comptes utilisés pour effectuer la sauvegarde ont le minimum de privilèges et que vous sécurisez les canaux de communication supplémentaires exposés uniquement pour la sauvegarde.

Résumé

En consacrant, en amont, du temps et des efforts à l'analyse et à l'examen de l'architecture et de la conception de votre application, vous pouvez en améliorer la sécurité globale en éliminant les vulnérabilités liées à la conception. Il est beaucoup plus facile et moins coûteux de corriger des vulnérabilités à la phase de conception que lors du cycle de développement qui nécessite une réingénierie plus importante.

En considérant votre conception par rapport à l'environnement de déploiement cible et aux stratégies de sécurité définies par cet environnement, vous pouvez favoriser le déploiement correct et sécurisé de votre application.

Si votre application a déjà été créée, l'examen de l'architecture et de la conception est une partie importante du processus d'évaluation de la sécurité qui vous aide à corriger les vulnérabilités et à améliorer les conceptions futures.

Informations complémentaires

Pour plus d'informations, reportez-vous aux ressources suivantes :

  • Pour plus d'informations sur la conception, la construction et la configuration de l'authentification, l'autorisation, et la sécurisation des communications à travers les couches des applications Web distribuées, reportez-vous à « Building Secure ASP.NET Web Applications: Authentication, Authorization, and Secure Communication » à l'adresse : http://msdn.microsoft.com/library/en-us/dnnetsec/html/secnetlpMSDN.asp.

  • Retrouvez la liste de contrôle imprimable « Liste de contrôle : examen de la sécurité de l'architecture et de la conception », dans la section « Listes de contrôle » de ce guide.

Afficher:
© 2015 Microsoft