Exporter (0) Imprimer
Développer tout

Menaces et contre-mesures

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

Dans ce module Dans ce module
Objectifs Objectifs
S'applique à S'applique à
Avant de commencer Avant de commencer
Anatomie d'une attaque Anatomie d'une attaque
Présentation des catégories de menaces Présentation des catégories de menaces
Menaces et contre-mesures concernant le réseau Menaces et contre-mesures concernant le réseau
Menaces et contre-mesures concernant l'hôte Menaces et contre-mesures concernant l'hôte
Menaces et contre-mesures concernant l'application Menaces et contre-mesures concernant l'application
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

Ce module analyse la sécurité des applications Web du point de vue des menaces, des contre-mesures, des vulnérabilités et des attaques. L'incorporation de fonctions de sécurité dans la conception, la mise en œuvre et le déploiement de votre application vous aide à acquérir une meilleure compréhension de la manière de penser des pirates. En essayant de vous mettre dans leur peau et de deviner leurs tactiques possibles, vous êtes plus efficace pour appliquer des contre-mesures. Ce module décrit les méthodes classiques des pirates et dresse un profil d'une attaque type.

Il commence par une introduction des méthodologies courantes adoptées par les pirates pour compromettre des applications Web et suggère le classement des menaces selon la méthode STRIDE. Il présente ensuite les principales menaces qui peuvent compromettre votre réseau, l'infrastructure de l'hôte et les applications. La connaissance de ces menaces et des contre-mesures correspondantes vous permet de disposer des informations essentielles pour procéder à une modélisation de la menace.

Grâce à ce module, vous allez pouvoir identifier les menaces spécifiques à votre scénario d'application et les classer selon le degré de risque qu'elles font peser sur votre système.

Objectifs

Ce module vous permettra :

  • d'apprendre à penser comme un pirate ;

  • de découvrir la méthode STRIDE couramment utilisée pour classifier les menaces ;

  • d'identifier et de contrer les menaces au niveau du réseau, de l'hôte et de l'application.

S'applique à

Application Web

Avant de commencer

Avant de commencer le processus de modélisation de la menace, il est important de connaître la terminologie de base.

  • Ressource. Élément de valeur, tel que les données d'une base ou d'un système de fichier, ou une ressource du système.

  • Menace. Événement potentiel, malveillant ou autre, qui peut nuire à une ressource.

  • Vulnérabilité. Faiblesse qui rend possible une menace.

  • Attaque (ou exploit). Action entreprise pour nuire à une ressource.

  • Contre-mesure. Mesure de protection qui contre une menace et atténue un risque.

Anatomie d'une attaque

En comprenant l'approche de base utilisée par les pirates qui s'attaquent à votre application Web, vous serez mieux à même de prendre les mesures de défense adéquates car vous saurez contre quoi vous devez lutter. Les étapes de base de la méthode d'un pirate sont récapitulées ci-après et illustrées dans la figure 2.1 :

  • Étude et évaluation

  • Exploitation et pénétration

  • Élévation des privilèges

  • Maintien de l'accès

  • Refus du service

Étapes de base d'une méthode d'attaque

Figure 2.1
Étapes de base d'une méthode d'attaque

Étude et évaluation

L'étude et l'évaluation de la cible potentielle ont lieu simultanément. En premier lieu, le pirate surveille la cible pour identifier et évaluer ses caractéristiques. Celles-ci incluent notamment les services pris en charge et des protocoles ainsi que les vulnérabilités potentielles et les points d'entrée. Le pirate utilise les informations recueillies au cours de cette phase pour planifier une attaque initiale.

Par exemple, il peut détecter une vulnérabilité de script inter-site (XSS) en vérifiant si les contrôles d'une page Web renvoient des éléments en sortie.

Exploitation et pénétration

L'étape suivante consiste à exploiter et à pénétrer le système. Si le réseau et l'hôte sont totalement sécurisés, votre application (le portail frontal) devient la prochaine voie d'attaque.

Pour un pirate, le plus facile pour pénétrer dans une application est de passer par la même entrée que les utilisateurs légitimes ; par exemple, par la page de connexion de l'application ou par une page qui n'exige pas d'authentification.

Élévation des privilèges

Une fois que le pirate a réussi à compromettre une application ou un réseau, par exemple en y injectant du code ou en créant une session authentifiée avec le système d'exploitation Microsoft® Windows® 2000, il tente immédiatement d'augmenter les privilèges. En particulier, il recherche les privilèges administratifs offerts par les comptes qui sont membre du groupe des administrateurs. Il cherche également à connaître le niveau des privilèges offerts par le compte système local.

L'utilisation de comptes de service avec un minimum de privilèges dans votre application constitue un moyen de défense essentiel contre les attaques basées sur l'élévation des privilèges. De même, de nombreuses attaques par élévation de privilèges au niveau du réseau requièrent une session de connexion interactive.

Maintien de l'accès

Une fois qu'il a accédé à un système, le pirate prend des mesures pour faciliter les futurs accès et dissimuler ses traces. Le plus courant pour ce faire consiste à inclure des programmes « backdoor » (porte de service) ou à utiliser un compte existant mal protégé. La dissimulation des traces implique habituellement d'effacer les journaux et de masquer les outils. Ainsi, les journaux d'audit sont une cible importante des pirates.

Les fichiers journaux doivent être sécurisés et analysés régulièrement. Leur analyse permet souvent de découvrir les premiers signes d'une tentative d'intrusion, avant que des dommages ne soient causés.

Refus du service

N'obtenant pas l'accès à un système, certains pirates lancent une attaque de type refus de service pour empêcher les utilisateurs d'accéder à l'application. Pour d'autres, le refus de service est leur objectif premier. La saturation SYN en est un exemple ; dans ce cas, le pirate utilise un programme pour envoyer un flot de requêtes SYN TCP de façon à saturer la file de connexions en attente sur le serveur. Les autres utilisateurs n'ont ainsi plus la possibilité d'établir des connexions avec le réseau.

Présentation des catégories de menaces

Devant les nombreuses variantes d'attaques et techniques d'attaque, il est utile de chercher à savoir, à travers les menaces, ce que le pirate tente d'obtenir. Ainsi, au lieu de vous concentrer sur l'identification de chaque attaque particulière, ce qui est juste un moyen pour atteindre un but, vous allez vous attacher aux résultats finals des attaques possibles.

STRIDE

Il est possible de classer les menaces qui pèsent sur l'application en fonction des objectifs des attaques. Une connaissance concrète des catégories de menaces peut vous aider à élaborer une stratégie de sécurité afin de disposer de réponses déjà planifiées à opposer aux menaces le moment venu. Microsoft a mis au point la méthode STRIDE pour classifier différents types de menaces. STRIDE est l'acronyme des expressions suivantes :

  • Spoofing (usurpation d'identité) : vise à obtenir l'accès à un système en utilisant une fausse identité. Le pirate utilise les informations d'identification volées d'un utilisateur ou une fausse adresse IP. Une fois qu'il a accès au système en tant qu'utilisateur ou hôte légitime, il peut commencer à augmenter les privilèges ou à mener son action malveillante.

  • Tampering (falsification des données) : consiste à modifier les données, par exemple lorsqu'elles circulent sur un réseau entre deux ordinateurs.

  • Repudiation (répudiation) : consiste pour un utilisateur (légitime ou non) à nier qu'il a accompli une action ou une transaction spécifique. Sans un audit adéquat, les attaques de répudiation sont difficiles à prouver.

  • Information disclosure (divulgation d'informations) : consiste à révéler des données confidentielles. Par exemple, un utilisateur voit le contenu d'une table ou d'un fichier qu'il n'est pas autorisé à ouvrir, ou il surveille les données qui passent en clair sur le réseau. Ce type de vulnérabilité inclut notamment l'utilisation de champs de formulaire cachés, des commentaires incorporés dans des pages Web qui contiennent des chaînes de connexion à la base de données et des données détaillées de connexion, ou encore une mauvaise gestion des exceptions pouvant conduire à la révélation au client d'informations internes précises sur le système. Toutes ces informations peuvent s'avérer utiles pour un pirate.

  • Denial of service (refus de service) : consiste à rendre un système ou une application indisponible. Par exemple, une attaque par refus de service va bombarder un serveur de requêtes de façon à utiliser toutes les ressources disponibles du système ou à transmettre des données non conformes qui peuvent détériorer un processus de l'application.

  • Elevation of privilege (élévation des privilèges) : se produit lorsqu'un utilisateur possédant des droits d'accès limités prend l'identité d'un utilisateur privilégié pour obtenir un accès privilégié à une application. Ainsi, un pirate disposant de privilèges limités peut augmenter leur niveau de façon à compromettre l'environnement et à prendre le contrôle d'un processus ou d'un compte sécurisé doté de privilèges élevés.

Menaces STRIDE et contre-mesures

À chaque catégorie de menaces décrite dans la méthode STRIDE correspond un ensemble de contre-mesures utilisables pour atténuer le risque. Ces contre-mesures sont décrites dans le tableau 2.1. La contre-mesure appropriée dépend de l'attaque. D'autres menaces, attaques et contre-mesures concernant les couches réseau, hôte et application sont présentées plus loin dans ce module.

Tableau 2.1 : Menaces STRIDE et contre-mesures

Menace

Contre-mesures

Usurpation d'identité

Utilisez une authentification sûre.
Ne stockez pas des données secrètes (mots de passe par exemple) en clair.
Ne transmettez pas en clair sur le réseau des informations d'identification.
Protégez les cookies d'authentification au moyen du protocole SSL (Secure Sockets Layer).

Falsification de données

Utilisez le hachage et la signature des données.
Adoptez des signatures numériques.
Utilisez des autorisations sûres.
Utilisez des protocoles résistants à la falsification sur les liaisons de communication.
Sécurisez les liaisons de communication avec des protocoles assurant l'intégrité des messages.

Répudiation

Créez des journaux d'audit sécurisés.
Utilisez des signatures numériques.

Divulgation d'informations

Utilisez des autorisations sûres.
Utilisez un cryptage fort.
Sécurisez les liaisons de communication avec des protocoles assurant la confidentialité des messages.
Ne stockez pas des données secrètes (mots de passe par exemple) en clair.

Refus de service

Limitez la bande passante et l'utilisation des ressources.
Validez et filtrez les données d'entrée.

Élévation des privilèges

Adoptez le principe du moindre privilège et utilisez des comptes de service ayant un minimum de privilèges pour exécuter des processus et accéder aux ressources.

Menaces et contre-mesures concernant le réseau

Les principaux composants qui constituent votre infrastructure de réseau sont des routeurs, des pare-feu et des commutateurs. Ils agissent comme opérateurs de contrôle protégeant vos serveurs et applications contre les attaques et les intrusions. Un pirate peut exploiter des dispositifs réseau mal configurés. Les vulnérabilités courantes sont notamment des paramètres d'installation par défaut mal définis, des contrôles d'accès largement ouverts et des périphériques dépourvus des derniers correctifs de sécurité. Les principales menaces contre le réseau incluent :

  • Collecte d'informations

  • Espionnage

  • Usurpation d'identité

  • Détournement de session

  • Refus de service

Collecte d'informations

Il est possible de découvrir les périphériques du réseau et d'en faire un profil, de la même manière que pour les autres types de système. Le pirate commence habituellement par l'analyse des ports. Lorsqu'il détecte un port ouvert, il utilise l'accrochage de bannière et l'énumération pour détecter les types de périphériques et déterminer les versions du système d'exploitation et de l'application.

Les contre-mesures visant à empêcher la collecte d'informations consistent notamment à :

  • configurer des routeurs pour limiter leurs réponses aux requêtes d'encombrement ;

  • configurer les systèmes d'exploitation qui hébergent le logiciel réseau (par exemple les pare-feu logiciels) pour éviter l'encombrement en désactivant les protocoles et les ports inutiles.

Espionnage

L'espionnage ou écoute clandestine désigne le processus consistant à surveiller le trafic du réseau à la recherche de données en texte clair, comme des mots de passe non codés, ou des informations de configuration. Avec un simple intercepteur de paquets, un pirate peut facilement lire tout le contenu du trafic en clair. De même, il peut décoder des paquets cryptés que vous jugez sûrs. L'espionnage des paquets nécessite la présence d'un intercepteur dans le chemin de communication serveur/client.

Les contre-mesures visant à empêcher l'espionnage consistent à :

  • utiliser un mécanisme de sécurité physique robuste et une segmentation adéquate du réseau. Il s'agit de la première étape pour éviter des collectes locales d'informations sur le trafic ;

  • crypter entièrement les communications, y compris les données d'authentification. De la sorte, les paquets interceptés ne sont pas utilisables par le pirate. Les protocoles SSL et IPSec (Internet Protocol Security) sont des exemples de solutions de cryptage.

Usurpation d'identité

L'usurpation d'identité consiste à dissimuler la véritable identité d'une personne sur le réseau. Pour usurper une identité, le pirate utilise une adresse source simulée qui ne représente pas l'adresse réelle du paquet. L'usurpation peut permettre de masquer l'origine d'une attaque ou de contourner les listes ACL d'accès au réseau mises en place pour limiter l'accès à l'hôte sur la base de règles relatives aux adresses source.

Bien qu'il soit quasiment impossible de remonter jusqu'à l'expéditeur de paquets soigneusement usurpés et manipulés, un ensemble de règles de filtrage évite que des paquets usurpés ne quittent votre réseau, ce qui permet de les bloquer.

Les contre-mesures visant à empêcher l'usurpation d'identité consistent à :

  • filtrer au niveau de votre périmètre les paquets entrants qui semblent venir d'une adresse IP interne ;

  • filtrer les paquets sortants qui semblent provenir d'une adresse IP locale non valide.

Détournement de session

Également connu sous le nom d'attaque par personne interposée, le détournement de session abuse un serveur ou un client en lui faisant accepter l'hôte en amont comme l'hôte réellement légitime. Mais en réalité, l'hôte en amont est celui du pirate qui manipule le réseau de telle sorte que son hôte semble être la destination souhaitée.

Les contre-mesures visant à empêcher le détournement de session consistent à :

  • utiliser une négociation de session cryptée ;

  • utiliser des voies de communication cryptées ;

  • se tenir au courant des correctifs de plates-formes récents afin de résoudre les vulnérabilités TCP/IP, comme les séquences de paquets prévisibles.

Refus de service

Le refus de service dénie aux utilisateurs légitimes l'accès à un serveur ou à des services. L'attaque par saturation SYN en est un exemple courant. Elle est facile à lancer et difficile à suivre. Le but de cette attaque est d'envoyer à un serveur plus de requêtes qu'il ne peut en traiter. Le refus de service exploite une vulnérabilité potentielle dans le mécanisme d'établissement de la connexion TCP/IP et sature la file des connexions en attente du serveur.

Les contre-mesures visant à empêcher le refus de service consistent à :

  • appliquer les tout derniers Service Packs ;

  • renforcer la pile TCP/IP en appliquant les paramètres de registre appropriés afin d'augmenter la taille de la file d'attente des connexions TCP, de diminuer le temps d'établissement de la connexion et de mettre en place des mécanismes de backlog dynamique afin de s'assurer que la file des connexions en attente n'est jamais saturée ;

  • utiliser un système IDS (systèmes de détection d'intrusion) car ceux-ci peuvent automatiquement détecter les attaques SYN et les contrer.

Menaces et contre-mesures concernant l'hôte

Les menaces contre l'hôte sont dirigées au niveau du logiciel système sur lequel s'appuient vos applications, à savoir Windows 2000, Internet Information Services (IIS), .NET Framework et SQL Server, selon le rôle de serveur spécifique. Les principales menaces au niveau de l'hôte sont les suivantes :

  • Virus, chevaux de Troie et vers

  • Encombrement

  • Profilage

  • Décodage (craquage) de mot de passe

  • Refus de service

  • Exécution arbitraire du code

  • Accès non autorisé

Virus, chevaux de Troie et vers

Un virus est un programme conçu pour exécuter des actes malveillants et perturber votre système d'exploitation ou vos applications. Un cheval de Troie ressemble à un virus, si ce n'est que le code malveillant est contenu dans ce qui semble être un fichier de données ou un programme exécutable inoffensif. Un ver est difficile à détecter car il ne crée pas régulièrement des fichiers susceptibles d'être vus. On ne remarque souvent sa présence que lorsqu'il commence à consommer les ressources du système car celui-ci se met à ralentir ou d'autres programmes s'arrêtent. Le ver Code Red est un des plus célèbres qui se soient attaqués à IIS ; il exploitait une vulnérabilité de dépassement de capacité de la mémoire tampon dans un filtre ISAPI spécifique.

Bien qu'il s'agisse en réalité d'attaques, ces menaces constituent à elles trois un danger important pour les applications Web, les hôtes qui les hébergent et le réseau qui sert à les diffuser. Le succès de ces attaques sur les systèmes est possible en raison des nombreuses faiblesses telles que des valeurs par défaut peu fiables, des bogues logiciels, des erreurs de l'utilisateur et des vulnérabilités inhérentes aux protocoles Internet.

Les contre-mesures utilisables face aux virus, chevaux de Troie et vers consistent à :

  • rester informé des tout derniers Service Packs du système d'exploitation et des correctifs de logiciel ;

  • bloquer tous les ports inutiles au niveau du pare-feu et de l'hôte ;

  • désactiver les fonctionnalités inutilisées, y compris les protocoles et les services ;

  • renforcer les paramètres de configuration par défaut peu sûrs.

Encombrement

Les analyses de ports, les balayages de Ping et les énumérations NetBIOS sont des exemples d'encombrement utilisables par les pirates pour récupérer des informations système intéressantes qui les aideront à préparer des attaques plus ciblées. Les informations susceptibles d'être révélées par un encombrement sont notamment les données détaillées des comptes, les versions du système d'exploitation et d'autres logiciels existants, les noms de serveur et les détails du schéma de la base de données.

Les contre-mesures visant à empêcher l'encombrement consistent à :

  • désactiver les protocoles inutiles ;

  • verrouiller les ports avec la configuration de pare-feu appropriée ;

  • utiliser les filtres TCP/IP et IPSec pour permettre une défense avancée ;

  • configurer IIS pour éviter la divulgation d'information via l'accrochage de bannière ;

  • utiliser un système IDS (système de détection d'intrusion) pour choisir des modèles d'encombrement et refuser tout trafic suspect.

Décodage de mot de passe

Si le pirate ne parvient pas à établir une connexion anonyme avec le serveur, il va tenter d'établir une connexion authentifiée. Pour ce faire, il doit connaître un nom d'utilisateur et un mot de passe valides. Si vous utilisez des noms de compte par défaut, vous lui simplifiez la tâche. Il lui suffit de décoder (craquer) le mot de passe du compte. L'utilisation de mots de passe simplistes, voire vides, facilite la tâche du pirate.

Les contre-mesures visant à empêcher le décodage des mots de passe consistent à :

  • utiliser des mots de passe forts pour tous les types de compte ;

  • appliquer des stratégies de verrouillage des comptes des utilisateurs finals afin de limiter le nombre de nouvelles tentatives de connexion qui pourraient servir à deviner le mot de passe ;

  • ne pas utiliser des noms de compte par défaut et renommer les comptes standard, tels que le compte de l'administrateur et le compte utilisateur Internet anonyme employés par de nombreuses applications Web ;

  • contrôler les connexions qui ont échoué et rechercher des modèles qui correspondraient à des tentatives de piratage de mot de passe.

Refus de service

Plusieurs méthodes, dirigées vers plusieurs cibles au sein de votre infrastructure, permettent d'entraîner un refus de service. Au niveau de l'hôte, un pirate peut détériorer le service en menant une attaque en force contre l'application, ou s'il connaît une faiblesse dans le service qui héberge votre application ou encore au niveau du système d'exploitation de votre serveur.

Les contre-mesures visant à empêcher le refus de service consistent à :

  • configurer vos applications, vos services et votre système d'exploitation en ayant ce type d'attaque à l'esprit ;

  • rester informé des derniers correctifs et des récentes mises à jour de sécurité ;

  • renforcer la pile TCP/IP contre les refus de service ;

  • vérifier que vos stratégies de verrouillage des comptes ne permettent pas de verrouiller des comptes de services connus ;

  • vous assurer que votre application peut gérer un trafic important et que des seuils appropriés ont été définis pour gérer des charges anormalement élevées ;

  • vérifier la fonctionnalité de basculement de votre application ;

  • utiliser un système IDS pour détecter les éventuelles attaques par refus de service.

Exécution arbitraire du code

Si un pirate parvient à exécuter un code malveillant sur votre serveur, il peut soit compromettre vos ressources, soit mener d'autres attaques contre des systèmes en aval. Les risques liés à l'exécution arbitraire du code augmentent si le processus serveur sous lequel s'exécute le code du pirate est associé à un maximum de privilèges. Les vulnérabilités courantes incluent notamment l'existence de serveurs sans correctifs et dotés d'une configuration d'IID insuffisante, qui permettent des attaques de pénétration de chemin d'accès et de dépassement de capacité de la mémoire tampon, l'une et l'autre pouvant conduire à une exécution arbitraire de code.

Les contre-mesures visant à empêcher l'exécution arbitraire de code consistent à :

  • configurer IIS pour refuser les adresses URL contenant "../", afin d'éviter la pénétration des chemins d'accès ;

  • verrouiller les commandes et les utilitaires système avec des listes ACL limitées ;

  • se renseigner sur les correctifs et les mises à jour existants pour pouvoir les installer aussi vite que possible lorsqu'ils concernent les dépassements de capacité de la mémoire tampon.

Accès non autorisé

Lorsque les contrôles d'accès sont inadaptés, un utilisateur non autorisé peut accéder à des informations restreintes ou exécuter des opérations limitées. Les vulnérabilités les plus fréquentes sont des contrôles d'accès au système Web IIS insuffisants, notamment des autorisations Web et NTFS non fiables.

Les contre-mesures visant à empêcher un accès non autorisé consistent à :

  • configurer des autorisations Web sécurisées ;

  • verrouiller les fichiers et les dossiers avec des autorisations NTFS limitées ;

  • utiliser des mécanismes de contrôle d'accès .NET Framework dans vos applications ASP.NET, y compris l'autorisation d'accès à l'URL et des demandes d'autorisation principales.

Menaces et contre-mesures concernant l'application

Un bon moyen pour analyser les menaces au niveau de l'application consiste à les classer en fonction des vulnérabilités propres à l'application. Les différentes catégories mentionnées dans la suite de la documentation, ainsi que les principales menaces pesant sur votre application, sont récapitulées dans le tableau 2.2.

Tableau 2.2 : Classement des menaces par catégorie de vulnérabilités des applications

Catégorie

Menaces

Validation des entrées

Dépassement de capacité de la mémoire tampon ; injection SQL ; canonisation

Authentification

Écoute clandestine du réseau ; attaque en force ; attaques par dictionnaire ; relecture de cookie ; vol d'informations d'identification

Autorisation

Élévation de privilèges ; divulgation de données confidentielles ; falsification de données, attaques par leurre

Gestion de la configuration

Accès non autorisé aux interfaces administratives ; accès non autorisé aux informations de configuration ; récupération de données de configuration en texte clair ; absence de gestion individuelle ; comptes de service et processus sur-privilégiés

Données sensibles

Accès aux données sensibles en cours de stockage ; écoute du réseau ; falsification des données

Gestion des sessions

Piratage de session ; relecture de session ; intrus

Cryptographie

Mauvaise génération et/ou gestion des clés ; cryptage peu sûr ou personnalisé

Manipulation des paramètres

Manipulation des chaînes de requête ; manipulation des champs de formulaire ; manipulation des cookies ; manipulation des en-têtes HTTP

Gestion des exceptions

Divulgation d'informations ; refus de service

Audit et journalisation

L'utilisateur refuse l'exécution d'une opération ; le pirate exploite une application sans laisser de trace ; le pirate dissimule ses traces

Validation des entrées

La validation des entrées pose un problème de sécurité si un pirate découvre que votre application se base sur des postulats infondés concernant le type, la longueur, le format ou la plage des données d'entrée. Il peut dès lors soigneusement manipuler les entrées pour compromettre votre application.

Lorsque les points d'entrée au niveau de l'hôte et du réseau sont totalement sécurisés, les interfaces publiques exposées par votre application deviennent la seule source d'attaque. Les entrées qui parviennent à votre application constituent un moyen pour tester votre système et pour faire exécuter du code au profit du pirate. Votre application fait-elle aveuglément confiance aux entrées ? Si c'est le cas, elle est toute désignée pour subir les attaques suivantes :

  • Dépassement de capacité de la mémoire tampon

  • Script inter-site

  • Injection SQL

  • Canonisation

La section suivante étudie ces vulnérabilités dans le détail, y compris les motifs qui les rendent possibles.

Dépassement de capacité de la mémoire tampon

Les faiblesses liées au dépassement de capacité de la mémoire tampon peuvent entraîner un refus de service ou une injection de code. Un refus de service provoque une défaillance du processus ; l'injection de code modifie l'adresse d'exécution du code pour exécuter le code injecté par le pirate. L'extrait de code suivant illustre un exemple courant de vulnérabilité vis-à-vis d'un dépassement de la capacité de mémoire.

void SomeFunction( char *pszInput )
{
  char szBuffer[10];
  // Lorsque aucune vérification de type n'a lieu, les entrées sont 
  copiées directement dans la mémoire tampon
  strcpy(szBuffer, pszInput);
  . . .
}

Le code .NET géré n'est pas sujet à ce problème car à chaque accès à un tableau, la taille de ce dernier est automatiquement vérifiée. Le risque de dépassement de la capacité de la mémoire tampon est donc moins aigu en présence de code géré. Toutefois, il reste présent, notamment lorsque le code géré appelle des API non gérées ou des objets COM.

Les contre-mesures visant à empêcher les dépassements de capacité de la mémoire tampon consistent à :

  • effectuer une validation minutieuse de la saisie. Il s'agit là de la première mesure à prendre contre les attaques par dépassement de capacité de la mémoire tampon. Certes, il peut toujours exister dans votre application un bogue qui permet aux données attendues de dépasser les limites d'un conteneur ; mais les entrées non prévues sont en fait la cause de cette vulnérabilité. Vous devez donc limiter les entrées en validant leur type, leur longueur, leur format et la plage concernée ;

  • si possible, limiter l'utilisation du code non géré par votre application et contrôler soigneusement les API non gérées afin de vous assurer que les entrées sont correctement validées ;

  • inspecter le code géré qui appelle l'API non gérée afin de vérifier que seules les valeurs appropriées sont transmises comme paramètres à l'API en question ;

  • utiliser l'indicateur /GS pour compiler du code développé avec le système de développement Microsoft Visual C++®. Cet indicateur entraîne l'introduction par le compilateur de contrôles de sécurité dans le code compilé. Ce n'est pas une solution infaillible ni une solution de remplacement pour votre code de validation spécifique ; toutefois, il protège votre code des attaques courantes par dépassement de capacité de la mémoire tampon. Pour plus d'informations, reportez-vous à la documentation de.NET Framework à l'adresse suivante : http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccore/html/vclrfGSBufferSecurity.asp et à l'article 325483 de la base de connaissances Microsoft « Support WebCast: Compiler Security Checks: The /GS compiler switch » à l'adresse http://support.microsoft.com.

Exemple d'injection de code par le biais de dépassements de capacité de la mémoire tampon

Un pirate peut exploiter une faiblesse liée au dépassement de capacité de la mémoire tampon pour injecter du code. Dans ce type d'attaque, il utilise une mémoire tampon non contrôlée dans le cadre d'un processus en fournissant une valeur d'entrée soigneusement construite qui écrase la pile du programme et modifie l'adresse de renvoi d'une fonction. De ce fait, l'exécution passe directement au code injecté par le pirate.

Le code du pirate finit généralement par s'exécuter dans le contexte de sécurité du processus, ce qui souligne d'autant l'importance à utiliser des comptes de processus avec un minimum de privilèges. Si la thread en cours est usurpée, le code du pirate s'exécute dans le contexte de sécurité défini par le jeton d'usurpation de la thread. La première chose que fait habituellement un pirate est d'appeler l'API RevertToSelf pour revenir au contexte de sécurité du niveau processus où il espère trouver des privilèges plus élevés.

Veillez à valider le type et la longueur des entrées, notamment avant d'appeler du code non géré, car ce dernier favorise particulièrement les dépassements de capacité de la mémoire tampon.

Script inter-site

Une attaque de script inter-site peut provoquer l'exécution arbitraire de code dans le navigateur d'un utilisateur pendant que celui-ci est connecté à un site Web sécurisé. L'attaque vise les utilisateurs de votre application et non l'application elle-même, mais elle utilise votre application comme véhicule.

Du fait que le navigateur télécharge le code du script à partir d'un site sécurisé, il n'a aucun moyen de savoir que ce code est hostile. Les zones de sécurité d'Internet Explorer ne proposent aucune défense. Puisque le code du pirate a accès aux cookies associés au site sécurisé et que ces derniers sont stockés sur l'ordinateur local de l'utilisateur, les cookies d'authentification d'un utilisateur sont typiquement la cible d'une attaque.

Exemple de script inter-site

Pour déclencher l'attaque, le pirate doit convaincre l'utilisateur de cliquer sur un lien hypertexte soigneusement falsifié, par exemple en incorporant ce lien dans un courrier électronique adressé à l'utilisateur ou en ajoutant un lien malveillant dans un envoi au groupe de discussion. Le lien pointe sur une page vulnérable de votre application, qui renvoie des entrées non validées au navigateur dans le flux des données de sortie HTML. Prenons par exemple les deux liens suivants :

Voici un lien légitime :

www.yourwebapplication.com/logon.aspx?username=bernard

Voici un lien malveillant :

www.yourwebapplication.com/logon.aspx?username=<script>alert('hacker code')</script>

Si l'application Web prend la chaîne de requête, échoue à la valider correctement puis la renvoie au navigateur, le code script s'exécute dans le navigateur. L'exemple précédent affiche un message contextuel inoffensif. Avec le script approprié, le pirate peut aisément récupérer le cookie d'authentification de l'utilisateur, l'envoyer sur son site, puis, comme s'il était l'utilisateur authentifié, transmettre une requête au site Web ciblé.

Les contre-mesures visant à empêcher les scripts inter-site consistent à :

  • effectuer une validation minutieuse de la saisie. Vos applications doivent s'assurer que les entrées provenant des chaînes de requête, des champs de formulaire et des cookies sont valides. Considérez toutes les entrées utilisateur comme des données potentiellement malveillantes et filtrez-les ou nettoyez-les avant qu'elles atteignent le code en aval. Pour toutes les entrées, vérifiez qu'il s'agit de valeurs valides connues et refusez toutes les autres. Utilisez des expressions régulières pour valider les entrées saisies dans des champs de formulaire HTML, des cookies et des chaînes de requête ;

  • utiliser les fonctions HTMLEncode et URLEncode pour coder les données de sortie contenant des valeurs saisies par l'utilisateur. Cette opération convertit un script exécutable en HTML inoffensif.

Injection SQL

Une attaque par injection SQL exploite les vulnérabilités de validation des entrées pour exécuter des commandes arbitraires dans la base de données. Elle se produit par exemple lorsque votre application construit, à partir de valeurs entrées, des instructions SQL dynamiques pour accéder à la base de données. Elle peut également avoir lieu si votre code utilise des procédures stockées qui transmettent des chaînes contenant des données utilisateurs non filtrées. Avec l'injection SQL, le pirate peut exécuter des commandes arbitraires dans la base de données. Le problème s'aggrave si l'application se connecte à la base au moyen d'un compte sur-privilégié. Dans ce cas, il peut passer par le serveur de la base de données pour exécuter des commandes du système d'exploitation et compromettre d'autres serveurs, en plus d'extraire, de manipuler et de détruire des données.

Exemple d'injection SQL

Votre application risque une attaque par injection SQL lorsque vous incorporez des entrées utilisateur non validées dans des requêtes de base de données. Le code qui construit des instructions SQL dynamiques avec des données utilisateur non filtrées est particulièrement vulnérable. Considérez le code suivant :

SqlDataAdapter myCommand = new SqlDataAdapter(
         "SELECT * FROM Users 
          WHERE UserName ='" + txtuid.Text + "'", conn);

Les pirates peuvent injecter du SQL en terminant l'instruction SQL prévue par une apostrophe suivie d'un point-virgule pour commencer une nouvelle commande, puis en exécutant la commande de leur choix. Considérez la chaîne de caractères suivantes saisie dans le champ txtuid.

'; DROP TABLE Customers -

Cette chaîne soumet l'instruction suivante à la base de données pour qu'elle y soit exécutée.

SELECT * FROM Users WHERE UserName=''; DROP TABLE Customers --'

Elle supprime la table Customers, en supposant que la connexion de l'application ait les autorisations suffisantes dans la base (autre raison pour utiliser une connexion avec un minimum de privilèges dans la base). Le double tiret (--) indique un commentaire SQL et sert à désactiver les autres caractères ajoutés par le programmeur, comme l'apostrophe de fin.

Remarque : le point-virgule n'est pas vraiment obligatoire. SQL Server exécutera deux commandes séparées par des espaces.

D'autres stratagèmes plus subtils sont possibles. Le fait de fournir cette entrée dans le champ txtuid  :

' OR 1=1 -

crée la commande :

SELECT * FROM Users WHERE UserName='' OR 1=1 -

1=1 étant toujours vraie, le pirate récupère toutes les lignes de données de la table Users.

Les contre-mesures visant à empêcher l'injection SQL consistent à :

  • effectuer une validation minutieuse de la saisie : votre application doit valider ses entrées avant tout envoi de requête à la base de données ;

  • utiliser des procédures stockées avec paramètres pour l'accès à la base de données afin que les chaînes d'entrée ne soient pas traitées comme des instructions exécutables ; si vous ne pouvez pas utiliser des procédures stockées, utilisez des paramètres SQL lorsque vous générez des commandes SQL ;

  • utiliser des comptes avec le minimum de privilèges pour vous connecter à la base de données.

Canonisation

Pour désigner certaines formes d'entrées qui, après résolution, produisent le même nom standard (nom canonique), on parle de canonisation. Un code est particulièrement vulnérable aux problèmes liés à la canonisation s'il base ses décisions de sécurité sur le nom d'une ressource transmis au programme sous forme d'entrée. Les fichiers, les chemins d'accès et les URL font partie de ces ressources vulnérables car, dans chaque cas, il existe de multiples façons de représenter le même nom. Les noms de fichiers sont eux aussi problématiques. Par exemple, vous pouvez désigner un même fichier sous les formes suivantes :

c:\temp\somefile.dat
somefile.dat
c:\temp\subdir\..\somefile.dat
c:\  temp\   somefile.dat
..\somefile.dat

Dans l'idéal, votre code ne doit pas accepter un nom de fichier en entrée. S'il le fait, il doit au préalable le convertir dans sa forme canonique avant de prendre une décision de sécurité, par exemple décider d'accorder ou refuser l'accès au fichier spécifié.

Les contre-mesures visant à lutter contre les problèmes de canonisation consistent à :

  • éviter si possible les noms de fichier en entrée et utiliser à la place des chemins d'accès absolus que l'utilisateur final ne peut pas modifier ;

  • s'assurer que les noms de fichier sont conformes (si vous devez toutefois les accepter en entrée) et les valider dans le contexte de votre application ; par exemple, vérifiez qu'ils figurent dans l'arborescence des répertoires de votre application ;

  • s'assurer que le codage des caractères est correctement défini de façon à limiter les modes de représentation des entrées. Vérifiez que le fichier Web.config de votre application a défini les attributs requestEncoding et responseEncoding à <globalization>.

Authentification

Selon vos besoins, vous avez le choix entre plusieurs mécanismes d'authentification. Si vous ne mettez pas en œuvre un dispositif adapté, le mécanisme d'authentification risque d'ouvrir des failles que les pirates exploiteront pour accéder à votre système. Les principales menaces liées aux faiblesses de l'authentification sont les suivantes :

  • Écoute clandestine du réseau

  • Attaques en force

  • Attaques de dictionnaire

  • Relecture de cookie

  • Vol des informations d'identification

Écoute clandestine du réseau

Si les informations d'authentification sont transmises en clair du client au serveur, un pirate peut, avec un simple logiciel de surveillance du réseau installé sur un hôte de ce même réseau, récupérer le trafic et obtenir les noms et les mots de passe des utilisateurs.

Les contre-mesures visant à empêcher l'écoute clandestine du réseau consistent à :

  • utiliser des mécanismes d'authentification qui ne transmettent pas le mot de passe en clair sur le réseau, tels que le protocole Kerberos ou le système d'authentification Windows ;

  • s'assurer que les mots de passe sont cryptés (si vous devez absolument les envoyer sur le réseau) ou utiliser un canal de communication crypté, par exemple avec SSL.

Attaques en force

Les attaques en force exploitent la puissance de calcul de l'ordinateur pour décoder des mots de passe hachés ou d'autres données secrètes sécurisées par hachage et cryptage. Pour atténuer le risque, utilisez des mots de passe forts.

Attaques de dictionnaire

Ce type d'attaque permet d'obtenir des mots de passe. La plupart des systèmes ne stockent pas les mots de passe en clair ou sous forme cryptée. Ils évitent en effet les mots de passe cryptés car une clé compromise met en danger tous les mots de passe figurant dans le magasin de données. Lorsque des clés sont perdues, tous les mots de passe sont invalidés.

La plupart des magasins d'utilisateurs mis en œuvre contiennent des mots de passe hachés (ou « digests »). Pour authentifier l'utilisateur, le système recalcule le mot haché sur la base du mot de passe entré par l'utilisateur et compare le résultat avec la valeur hachée stockée dans la base. Si un pirate parvient à se procurer la liste des mots de passe hachés, il peut lancer une attaque en force pour les décoder.

Dans l'attaque de type dictionnaire, le pirate utilise un programme qui parcourt tout le dictionnaire (ou plusieurs dictionnaires en différentes langues) et calcule la valeur hachée de chaque mot. Le hachage obtenu est comparé à la valeur stockée dans le magasin de données. Les mots de passe peu sûrs, tels que « Yankees » (une équipe célèbre) ou « Mustang » (votre voiture favorite ?) sont facilement décodés. Des mots plus sûrs, tels que « ?V'TrOuveReZPaSmoNMotdePAsse! », sont moins évidents à découvrir !

Remarque : une fois que le pirate dispose de la liste des mots de passe hachés, l'attaque de type dictionnaire peut se dérouler hors ligne et n'exige aucune interaction avec l'application.

Les contre-mesures visant à empêcher les attaques de dictionnaire consistent à :

  • utiliser des mots de passe sûrs de forme complexe, qui ne sont pas des mots standard et qui mélangent majuscules, minuscules, nombres et caractères spéciaux ;

  • enregistrer dans le magasin d'utilisateurs des mots de passe hachés non réversibles ; en outre, associer un salt (chiffre aléatoire généré par cryptage) au hachage du mot de passe.

Pour plus d'informations sur le stockage des mots de passe hachés avec un salt, reportez-vous au module 14, « Création d'un accès sécurisé aux données ».

Relecture de cookie

Dans ce type d'attaque, le pirate s'empare du cookie d'authentification de l'utilisateur grâce à un logiciel de surveillance, puis il relit ce cookie à l'application de façon à y accéder sous une fausse identité.

Les contre-mesures visant à empêcher la relecture de cookie consistent à :

  • utiliser un canal de communication crypté fourni par SSL chaque fois qu'un cookie d'authentification est transmis ;

  • adopter un délai d'attente de cookie qui déclenche l'authentification après un intervalle de temps relativement court : bien que cette solution n'empêche pas les attaques par relecture de cookie, elle réduit le laps de temps pendant lequel le pirate peut relire une requête sans devoir s'authentifier à nouveau suite à l'expiration de la session.

Vol des informations d'identification

Si votre application met en œuvre son propre magasin d'utilisateurs contenant les noms de leurs comptes et leurs mots de passe, comparez sa sécurité avec les bases d'identification fournies par la plate-forme, par exemple le magasin d'utilisateurs de Microsoft Active Directory® ou de Security Accounts Manager (SAM). L'historique du navigateur et le cache gardent aussi en mémoire les informations de connexion pour un usage ultérieur. Si d'autres personnes que l'utilisateur précédemment connecté ont accès au terminal et si la même page est récupérée, le login sauvegardé sera disponible.

Les contre-mesures visant à empêcher le vol d'informations d'identification consistent à :

  • utiliser et imposer des mots de passe sûrs ;

  • enregistrer des vérificateurs de mot de passe sous la forme de hachage unidirectionnel avec un salt ;

  • mettre en place le verrouillage des comptes d'utilisateurs finals après un certain nombre de tentatives de connexion ;

  • pour éviter que le cache du navigateur n'autorise l'accès au login, créer une fonctionnalité qui permettra à l'utilisateur soit de ne pas sauvegarder les données d'identification, soit d'adopter cette fonctionnalité comme stratégie par défaut.

Autorisation

En fonction de l'identité de l'utilisateur et de son appartenance à un rôle, l'autorisation d'accès à une ressource ou à un service est soit accordée, soit refusée. Les principales menaces qui exploitent les vulnérabilités liées à l'autorisation incluent :

  • Élévation des privilèges

  • Divulgation de données confidentielles

  • Falsification de données

  • Attaques par leurre

Élévation des privilèges

Lorsque vous concevez un modèle d'autorisation, pensez au pirate qui cherche à élever les privilèges d'un compte puissant, tel que celui d'un membre du groupe des administrateurs locaux ou le compte système local. Ce faisant, le pirate est capable de prendre le contrôle total de l'application et de la machine locale. Par exemple, avec une programmation ASP classique, l'appel de l'API RevertToSelf par un composant peut entraîner l'exécution de la thread active en tant que compte système local disposant des privilèges et des prérogatives maximum sur la machine locale.

La principale contre-mesure pour éviter l'élévation des privilèges est d'utiliser des comptes utilisateur, service et processus ayant un minimum de privilèges.

Divulgation de données confidentielles

La divulgation de données confidentielles peut se produire lorsque des utilisateurs non autorisés parviennent à visualiser des données sensibles. Il s'agit de données propres à l'application, telles que des numéros de carte de crédit, des éléments concernant les employés, des enregistrements financiers, etc., ainsi que des données de configuration de l'application comme les éléments d'identification des comptes de service et les chaînes de connexion à la base de données. Pour éviter la divulgation des données confidentielles, vous devez les sécuriser lorsqu'elles sont stockées de manière persistante, comme dans des bases de données et des fichiers de configuration, mais aussi durant leur transit sur le réseau. Seuls les utilisateurs authentifiés et autorisés doivent pouvoir accéder aux données qui leur sont spécifiques. L'accès aux données de configuration du système ne doit être accordé qu'aux administrateurs.

Les contre-mesures visant à empêcher la divulgation de données confidentielles consistent à :

  • effectuer des vérifications de rôle avant d'autoriser l'accès aux opérations susceptibles de révéler des données sensibles ;

  • utiliser des listes ACL pour sécuriser les ressources Windows ;

  • utiliser un cryptage standard pour stocker les données sensibles dans des bases de données et des fichiers de configuration.

Falsification de données

La falsification des données consiste à modifier des données sans en avoir l'autorisation.

Les contre-mesures visant à empêcher la falsification des données consistent à :

  • utiliser des contrôles d'accès sécurisés pour protéger les données stockées de manière persistante afin que seuls les utilisateurs autorisés puissent y accéder et les modifier ;

  • utiliser une sécurité basée sur les rôles afin de différencier les utilisateurs qui peuvent visualiser les données de ceux qui peuvent les modifier.

Attaques par leurre

Une attaque par leurre se produit lorsqu'une entité dotée de peu de privilèges est capable de faire en sorte qu'une autre entité plus privilégiée exécute une action en son nom.

Pour contrer cette menace, vous devez restreindre l'accès au code sécurisé avec l'autorisation appropriée. À cet égard, la sécurité d'accès au code de .NET Framework facilite le processus d'autorisation du code appelant pour tout accès à une ressource sécurisée ou pour toute exécution d'une opération privilégiée.

Gestion de la configuration

Bon nombre d'applications prennent en charge des interfaces de gestion de la configuration et offrent une fonctionnalité qui permet aux opérateurs et aux administrateurs de changer les paramètres de configuration, de mettre à jour le contenu d'un site Web et d'effectuer la maintenance de routine. Les principales menaces liées à la gestion de la configuration sont les suivantes :

  • Accès non autorisé aux interfaces d'administration

  • Accès non autorisé aux configurations stockées

  • Récupération de données secrètes de configuration en texte clair

  • Absence de gestion individuelle

  • Comptes service et processus sur-privilégiés

Accès non autorisé aux interfaces d'administration

Les interfaces d'administration sont souvent fournies par le biais de pages Web supplémentaires ou d'applications Web distinctes ; elles permettent aux administrateurs, aux opérateurs et aux développeurs de contenu de gérer le contenu et la configuration d'un site. Ces interfaces ne doivent être accessibles qu'à des utilisateurs restreints et autorisés. Les utilisateurs malveillants capables d'accéder à une fonction de gestion de la configuration peuvent endommager le site Web, accéder aux systèmes et aux bases de données situés en aval, ou mettre l'application hors service en détériorant les données de configuration.

Les contre-mesures visant à éviter un accès non autorisé à des interfaces d'administration consistent à :

  • limiter le nombre d'interfaces d'administration ;

  • utiliser une authentification fiable, par exemple avec des certificats ;

  • utiliser un mécanisme d'autorisation sûr avec plusieurs opérateurs de contrôle ;

  • assurer uniquement l'administration locale. Si une administration à distance est absolument nécessaire, utilisez des canaux cryptés, par exemple en adoptant la technologie VPN ou le protocole SSL, en raison de la nature sensible des données qui transitent sur les interfaces d'administration. Pour atténuer davantage le risque, envisagez aussi les stratégies IPSec pour limiter l'administration à distance aux ordinateurs du réseau interne.

Accès non autorisé aux configurations stockées

En raison de la nature sensible des données qui figurent dans les configurations stockées, vous devez adopter une sécurisation adéquate.

Les contre-mesures visant à protéger les configurations stockées consistent à :

  • configurer des listes ACL restreintes pour les fichiers de configuration de type texte, tels que Machine.config et Web.config ;

  • conserver les configurations stockées hors de l'espace Web, ce qui évite le risque de téléchargement par un pirate des configurations du serveur Web en vue d'exploiter ses vulnérabilités.

Récupération de données secrètes de configuration en texte clair

La restriction de l'accès aux configurations stockées est un avantage supplémentaire. Dans le cadre d'une défense élaborée, vous devez crypter les données telles que les mots de passe et les chaînes de connexion. Vous éviterez ainsi que des pirates ne se procurent des données de configuration sensibles. Le cryptage permet aussi que des administrateurs et des employés malveillants et hostiles n'obtiennent des informations sensibles telles que les chaînes de connexion à la base de données et les données d'identification des comptes qui pourraient leur permettre d'accéder à d'autres systèmes.

Absence de gestion individuelle

L'absence d'audit et de journalisation des modifications apportées à la configuration empêche de savoir quand des changements ont eu lieu et qui en est à l'origine. Lorsqu'une modification de comportement visant à octroyer un accès privilégié est effectuée, que ce soit par un opérateur honnête ou par un utilisateur malveillant, il faut immédiatement l'annuler. Appliquez ensuite des mesures préventives pour éviter que des modifications de ce type ne se reproduisent. N'oubliez pas qu'il est possible de contourner l'audit et la journalisation par le biais d'un compte partagé ; ceci concerne aussi bien les comptes de service, d'application et d'utilisateur que les comptes administratifs. Ces derniers ne doivent pas être partagés. L'affectation des comptes de service, d'application et d'utilisateur doit se faire à un niveau qui permette d'identifier une source d'accès unique par le biais du compte, et qui puisse faire état des modifications éventuelles apportées au privilège de ce compte.

Comptes de service et d'application sur-privilégiés

Si les comptes de service et d'application disposent d'un accès permettant de modifier les informations de configuration du système, un pirate peut sans problème les manipuler. Pour atténuer ce risque, utilisez des comptes d'application et de service possédant un minimum de privilèges. N'autorisez pas les comptes à modifier leurs propres données de configuration, sauf obligation explicite dans le cadre de la conception.

Données sensibles

Les données sensibles sont sujettes à de multiples menaces. Les attaques qui tentent de visualiser ou de modifier des informations sensibles peuvent viser les réseaux et les magasins de données. Les principales menaces qui pèsent sur les données sensibles sont les suivantes :

  • Accès à des données sensibles stockées

  • Écoute clandestine du réseau

  • Falsification de données

Accès à des données sensibles stockées

Sécurisez les données sensibles stockées pour éviter qu'un utilisateur, malveillant ou autre, n'y accède et ne les lise.

Les contre-mesures visant à protéger les données sensibles stockées consistent à :

  • utiliser des listes ACL restreintes pour les données persistantes stockées contenant des éléments sensibles ;

  • stocker des données cryptées ;

  • utiliser un mécanisme d'identité et d'autorisation basé sur les rôles, de sorte que seuls les utilisateurs possédant l'autorité voulue accèdent aux données sensibles. Utilisez une sécurité basée sur les rôles pour différencier les utilisateurs qui peuvent visualiser les données de ceux qui peuvent les modifier.

Écoute clandestine du réseau

Les données HTTP pour une application Web circulent sur les réseaux en texte clair et sont donc vulnérables aux attaques de type écoute clandestine du réseau, où le pirate utilise un logiciel de surveillance pour capter et éventuellement modifier les données sensibles.

Les contre-mesures visant à empêcher l'écoute clandestine du réseau consistent à :

  • crypter les données ;

  • utiliser un canal de communication crypté, par exemple SSL.

Falsification de données

La falsification des données consiste à modifier les données sans en avoir l'autorisation, le plus souvent lorsqu'elles transitent sur le réseau.

Une contre-mesure possible est de protéger les données sensibles en transit sur le réseau au moyen de protocoles résistant à la falsification, tels que HMAC.

Un HMAC assure l'intégrité des messages de la façon suivante :

  1. L'émetteur utilise une clé secrète partagée pour créer un hachage sur la base de la charge utile du message.

  2. Il transmet ce hachage avec la charge utile du message.

  3. Le destinataire utilise la clé partagée pour recalculer le hachage à partir de la charge utile reçue. Puis il compare la nouvelle valeur hachée avec celle qui lui a été transmise. Si les valeurs sont identiques, le message n'a pas pu être falsifié.

Gestion des sessions

La gestion des sessions dans les applications Web relève de la couche application. La sécurité d'une session est essentielle pour la sécurité globale de l'application.

Les principales menaces concernant la gestion des sessions sont les suivantes :

  • Détournement de session

  • Relecture de session

  • Intrus

Détournement de session

Un détournement de session a lieu lorsque le pirate utilise un logiciel de surveillance du réseau pour capter le jeton d'authentification (souvent un cookie) représentant la session d'un utilisateur dans une application. Avec le cookie récupéré, le pirate peut prendre la place de l'utilisateur et accéder à l'application. Il dispose alors des mêmes privilèges que l'utilisateur légitime.

Les contre-mesures visant à empêcher le détournement de session consistent à :

  • utiliser le protocole SSL pour créer un canal de communication sécurisé et ne transmettre que le cookie d'authentification dans le cadre d'une connexion HTTPS ;

  • mettre en place une fonctionnalité de déconnexion permettant à l'utilisateur de mettre fin à une session et qui impose une authentification en cas de démarrage d'une autre session ;

  • si vous n'utilisez pas le protocole SSL, s'assurer que la période d'expiration associée au cookie de session est limitée. Cette mesure n'empêche pas le détournement de la session, mais elle réduit le temps dont peut profiter le pirate.

Relecture de session

La relecture de session a lieu lorsque le jeton de session d'un utilisateur est intercepté et que le pirate s'en sert pour contourner l'authentification. Par exemple, si le jeton de session est en texte clair dans un cookie ou une URL, un pirate peut l'intercepter. Il lui suffit alors d'envoyer une requête en utilisant le jeton détourné.

Les contre-mesures visant à gérer la menace de relecture d'une session consistent à :

  • s'authentifier une nouvelle fois lors de l'exécution de fonctions stratégiques ; par exemple, avant de procéder à un transfert monétaire dans une application bancaire, obligez l'utilisateur à saisir à nouveau le mot de passe de son compte ;

  • définir un délai d'expiration des sessions correct, y compris des cookies et des jetons ;

  • créer une option « ne pas me rappeler » afin qu'aucune donnée de session ne soit stockée sur le client.

Attaques du type « intrus »

Une attaque de ce type se produit lorsque le pirate intercepte des messages échangés entre vous et votre destinataire. Il modifie alors votre message et l'envoie au destinataire. Celui-ci reçoit le message et, voyant qu'il vient de vous, le traite. Lorsqu'il vous adresse sa réponse, le pirate l'intercepte, la modifie et vous la fait suivre. Ainsi, ni vous ni votre destinataire ne savez que vous avez subi une attaque.

Les requêtes réseau qui impliquent des communications client-serveur, y compris des requêtes Web, des requêtes DCOM (Distributed Component Object Model) et des appels à des composants distants ou à des services Web, sont vulnérables aux attaques de type « intrus ».

Les contre-mesures visant à empêcher ce type d'attaque consistent à :

  • utiliser la cryptographie : en effet, si vous cryptez les données avant de les transmettre, le pirate peut toujours les intercepter mais il ne peut pas les lire ni les modifier. S'il ne les lit pas, il ne peut pas savoir quelles parties modifier. S'il modifie à l'aveuglette votre message crypté, le destinataire prévu ne pourra pas le décrypter et saura qu'il y a eu falsification ;

  • utiliser des codes HMAC (Hashed Message Authentication Codes). Si un pirate modifie le message, le recalcul du HMAC au niveau du destinataire échoue et les données sont refusées comme n'étant pas valides.

Cryptographie

La plupart des applications ont recours à la cryptographie pour protéger les données et garantir qu'elles demeurent confidentielles et inchangées. Les principales menaces liées à la cryptographie sont les suivantes :

  • Génération des clés ou gestion des clés insuffisante

  • Mauvais cryptage ou cryptage personnalisé insuffisant

  • Détournement de total de contrôle (checksum)

Génération des clés ou gestion des clés insuffisante

Les pirates peuvent décoder des données cryptées s'ils accèdent à la clé de cryptage ou l'obtiennent par dérivation. Ils y parviennent le cas échéant si les clés sont mal gérées ou si elles sont été générées de manière non aléatoire.

Les contre-mesures visant à lutter contre une mauvaise génération ou gestion des clés consistent à :

  • utiliser des routines de cryptage intégrées proposant une gestion sécurisée des clés ; l'interface DPAPI (Data Protection application programming interface) est un exemple de service de cryptage fourni avec Windows 2000 et les systèmes d'exploitation ultérieures, lesquels gèrent la clé ;

  • adopter un mode aléatoire et sûr de génération des clés et stocker la clé dans un emplacement restreint, par exemple dans une clé de registre sécurisée avec une ACL limitée, notamment si vous utilisez un mécanisme de cryptage exigeant la génération ou la gestion de la clé ;

  • crypter la clé de cryptage en utilisant la DPAPI pour accroître davantage la sécurité ;

  • définir régulièrement des délais d'expiration des clés.

Mauvais cryptage ou cryptage personnalisé insuffisant

Un algorithme de cryptage ne prévoit aucune sécurité en cas de décodage et il est vulnérable aux attaques en force. Les algorithmes personnalisés sont particulièrement sensibles aux attaques s'ils n'ont pas fait l'objet de tests rigoureux. Utilisez plutôt des algorithmes de cryptage connus qui ont fait leurs preuves en termes de surveillance et de réponses aux attaques.

Les contre-mesures visant à remédier aux faiblesses d'un cryptage insuffisant ou personnalisé consistent à :

  • ne pas développer vos propres algorithmes ;

  • utiliser les services de cryptage éprouvés, fournis avec la plate-forme ;

  • se renseigner sur les algorithmes piratés et les techniques employées pour les décoder.

Détournement de total de contrôle (checksum)

Ne comptez pas sur le hachage pour assurer l'intégrité des messages transmis sur le réseau. Les données hachées à l'aide d'algorithmes tels que SHA1 (Safe Hash Algorithm) et l'algorithme de compression MD5 (Message Digest) peuvent être interceptées et modifiées. Examinez le message suivant UTF-8 codé en base 64 associé à un code d'authentification de message (MAC).

Texte en clair : Émettre 10 commandes.
Hachage : T0mUNdEQh13IO9oTcaP4FYDX6pU=

Si un pirate intercepte le message suite à une surveillance du réseau, il peut le modifier et recalculer le hachage (en devinant l'algorithme employé). Ainsi, le message peut devenir :

Texte en clair : Émettre 100 commandes.
Hachage : oEDuJpv/ZtIU7BXDDNv17EAHeAU=

Lorsque le destinataire va traiter le message, qu'il aura le texte en clair (« Émettre 100 commandes ») après application de l'algorithme de hachage et qu'il recalculera la valeur hachée, celle-ci sera égale à ce que le pirate a calculé.

Pour contrer ce type d'attaque, utilisez un code MAC ou HMAC. L'algorithme standard TripleDES (Triple Data Encryption) pour les codes MAC calcule un code MAC et l'algorithme HMACSHA1 calcule un code HMAC. Les deux utilisent une clé pour produire un total de contrôle (checksum). Avec ces algorithmes, un pirate doit connaître la clé pour générer un total de contrôle qui produit un calcul correct chez le récepteur.

Manipulation des paramètres

La manipulation des paramètres appartient à une catégorie d'attaques qui s'appuient sur la modification des paramètres échangés entre le client et l'application Web. Il peut s'agir de chaînes de requête, de champs de formulaire, de cookies et d'en-tête HTTP. Les principales menaces du type manipulation des paramètres sont les suivantes :

  • Manipulation des chaînes de requête

  • Manipulation des champs de formulaire

  • Manipulation des cookies

  • Manipulation des en-têtes HTTP

Manipulation des chaînes de requête

Les utilisateurs peuvent facilement manipuler les valeurs d'une chaîne de requête transmise par l'instruction HTTP GET du client au serveur, puisqu'elles sont affichées dans la barre de l'adresse URL du navigateur. Si des décisions de sécurité sont prises sur la base des valeurs des chaînes de requête ou si les valeurs représentent des données sensibles comme des montants financiers, l'application est vulnérable aux attaques.

Les contre-mesures visant à gérer la menace de manipulation des chaînes de requêtes consistent à :

  • éviter d'utiliser des paramètres de chaîne de requête contenant des données sensibles ou susceptibles d'influer sur la logique sécuritaire du serveur ; utilisez plutôt un identificateur de session pour identifier le client et conservez les éléments sensibles dans la session stockée sur le serveur ;

  • choisir HTTP POST plutôt que GET pour soumettre les formulaires ;

  • crypter les paramètres des chaînes de requête.

Manipulation des champs de formulaire

Les valeurs des champs de formulaire HTML sont envoyées en clair au serveur via le protocole HTTP POST. Il peut y avoir des champs visibles et masqués. Les champs de formulaires, quel que soit leur type, sont faciles à modifier et les routines de validation côté client sont également faciles à contourner. Par conséquent, les applications qui prennent des décisions de sécurité au niveau serveur en s'appuyant sur des valeurs saisies dans les champs d'un formulaire sont vulnérables aux attaques.

Pour contrer la menace d'une manipulation des champs d'un formulaire, utilisez, au lieu des champs masqués, des identifiants de session pour référencer l'état géré tel qu'il est stocké sur le serveur.

Manipulation des cookies

Les cookies peuvent être modifiés par le client, qu'ils soient persistants ou résidants en mémoire. Il existe des outils pour aider un pirate à modifier le contenu d'un cookie résidant en mémoire. La manipulation de cookie consiste à modifier le cookie, généralement en obtenant un accès non autorisé à un site Web.

Même si SSL protège les cookies sur le réseau, il n'empêche pas leur modification sur l'ordinateur client. Pour lutter contre cette menace, cryptez ou utilisez un code HMAC avec le cookie.

Manipulation des en-têtes HTTP

Les en-têtes HTTP permettent l'échange d'informations entre le client et le serveur. Le client construit des en-têtes de requêtes et le serveur construit des en-têtes de réponse. Si votre application prend des décisions sur la base des en-têtes de requête, elle est vulnérable aux attaques.

Ne comptez jamais sur des en-têtes HTTP pour prendre des décisions de sécurité. Par exemple, ne faites jamais confiance au référant HTTP pour déterminer l'origine d'un client, car cette information est facile à falsifier.

Gestion des exceptions

Les exceptions dont la diffusion au client est autorisée peuvent révéler des informations de mise en œuvre interne qui n'ont aucun sens pour l'utilisateur final mais qui sont en revanche utiles pour les pirates. Les applications qui n'ont pas recours à la gestion des exceptions ou qui les gèrent de manière incomplète sont également vulnérables aux refus de service. Les principales menaces liées à la gestion des exceptions sont les suivantes :

  • Révélation par le pirate de données de mise en œuvre détaillées

  • Refus de service

Révélation par le pirate de données de mise en œuvre détaillées

Une des fonctionnalités importantes de .NET Framework est de fournir des informations détaillées sur les exceptions, qui sont véritablement utiles aux développeurs. Or, si ces mêmes informations tombent aux mains d'un pirate, elles l'aideront à exploiter les vulnérabilités potentielles du système et à planifier de futures attaques. Ce sont notamment les numéros de version de la plate-forme, les noms de serveur, les chaînes de commandes SQL et les chaînes de connexion à la base de données.

Les contre-mesures visant à lutter contre la révélation des données détaillées de mise en œuvre consistent à :

  • appliquer une gestion des exceptions à l'ensemble du code de votre application ;

  • gérer et consigner dans un journal les exceptions capables de se propager au-delà des limites de l'application ;

  • renvoyer des messages d'erreur génériques et non stratégiques au client.

Refus de service

Les pirates testent une application Web, généralement en transmettant des entrées volontairement mal conformées. Ils ont souvent deux objectifs en tête : le premier est de provoquer des exceptions qui leur révèlent par retour des informations utiles ; le second est d'endommager l'application. Cette attaque est possible si les exceptions sont mal interceptées et mal gérées.

Les contre-mesures visant à empêcher le refus de service au niveau de l'application consistent à :

  • valider soigneusement toutes les entrées au niveau du serveur ;

  • appliquer une gestion des exceptions à l'ensemble du code de votre application ;

Audit et journalisation

L'audit et la journalisation doivent faciliter la détection d'actions suspectes, telles que des tentatives d'encombrement ou des décodages de mots de passe, avant que des dégâts ne soient causés. Ils peuvent aussi aider à lutter contre la répudiation. Un utilisateur aura plus de difficulté à nier une transaction si plusieurs entrées de journal synchronisées sur plusieurs serveurs prouvent qu'il l'a effectivement effectuée.

Les principales menaces liées à l'audit et à la journalisation sont les suivantes :

  • Refus de la part de l'utilisateur d'exécuter une transaction

  • Exploitation par les pirates d'une application sans laisser de trace

  • Dissimulation par les pirates de leurs traces

Refus de la part de l'utilisateur d'exécuter une transaction

La répudiation consiste pour un utilisateur à nier qu'il a effectué une opération ou déclenché une transaction. Vous devez donc disposer de mécanismes de défense pour vous assurer que toutes les activités des utilisateurs sont suivies et enregistrées.

Les contre-mesures visant à lutter contre les menaces de répudiation consistent à :

  • réaliser un audit et une journalisation des activités sur le serveur Web et sur le serveur de la base de données, ainsi que sur le serveur d'applications le cas échéant ;

  • consigner dans un journal les événements majeurs tels que les transactions et les connexions/déconnexions ;

  • ne pas utiliser de comptes partagés tant que la source ne peut pas être déterminée.

Exploitation par les pirates d'une application sans laisser de trace

Un audit au niveau du système et de l'application est obligatoire pour que les éventuelles activités suspectes ne passent pas inaperçues.

Les contre-mesures visant à détecter les activités suspectes consistent à :

  • consigner dans un journal les opérations stratégiques au niveau de l'application ;

  • effectuer un audit au niveau de la plate-forme pour surveiller les événements de connexion/déconnexion, les accès au système de fichiers et les tentatives infructueuses d'accès à des objets ;

  • sauvegarder les fichiers journaux et les analyser régulièrement pour détecter les signes d'une éventuelle activité suspecte.

Dissimulation par les pirates de leurs traces

Vos fichiers journaux doivent être bien protégés pour éviter que les pirates ne couvrent leurs traces.

Les contre-mesures visant à éviter la dissimulation des traces d'intrusion par les pirates consistent à :

  • sécuriser les fichiers journaux en utilisant des listes ACL restreintes ;

  • déplacer les journaux système loin de leur emplacement par défaut.

Résumé

En ayant connaissance de l'approche adoptée habituellement par les pirates ainsi que leurs objectifs, vous serez plus performants dans l'application des contre-mesures. En outre, lorsque vous examinez et identifiez les menaces, cette connaissance doit vous aider à définir une approche basée sur les objectifs et à appliquer le modèle STRIDE pour classer les menaces en fonction des objectifs des pirates : par exemple, usurpation d'identité, falsification des données, refus de service, élévation des privilèges, etc. Ceci vous permet de vous concentrer davantage sur les démarches générales à mettre en place pour atténuer le risque au lieu de chercher à tout prix à identifier les attaques possibles, ce qui peut conduire à une perte de temps et ne déboucher sur rien de positif.

Ce module vous a présenté les principales menaces qui pèsent sur votre réseau, sur votre hôte et sur vos applications. Une bonne compréhension de ces menaces et des contre-mesures qui les accompagnent vous permet de disposer des informations nécessaires pour modéliser la menace. Vous pouvez ainsi identifier les menaces spécifiques à votre contexte et les classer en fonction du risque qu'elles représentent. Ce processus structuré visant à identifier et à classer les menaces est appelé modélisation de la menace. Pour plus d'informations, reportez-vous au module 3, « Modélisation de la menace ».

Informations complémentaires

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

  • Pour plus d'informations sur les menaces et contre-mesures relatives au réseau, reportez-vous au module 15, « Sécurisation de votre réseau ».

  • Pour plus d'informations sur les menaces et contre-mesures relatives à l'hôte, reportez-vous aux modules 16, « Sécurisation de votre serveur Web », 17, « Sécurisation de votre serveur d'applications », 18, « Sécurisation de votre serveur de base de données » et 19, « Sécurisation de votre application ASP.NET ».

  • Pour plus d'informations sur la prise en compte des menaces au niveau de l'application telles qu'elles sont présentées dans ce module, reportez-vous à la Création de modules dans la Partie III, « Création d'applications Web sécurisées » de ce guide.

  • Michael Howard et David LeBlanc, Writing Secure Code 2ème édition. Microsoft Press, Redmond, WA, 2002

  • Pour plus d'informations sur le suivi et la résolution des dépassements de capacité de la mémoire tampon, reportez-vous à l'article MSDN « Sus aux saturations de tampon ! » à l'adresse http://www.microsoft.com/france/msdn/visualc/articles/20020708_secure.mspx.

Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2015 Microsoft