Sécurité des applications Web

Les débuts du Web

   La première implémentation du protocole HTTP au sein du projet W3 était la version 0.9. Les spécifications de cette implémentation portaient sur trois éléments :
– l’ouverture de la connexion : le client ouvre une connexion TCP/IP en spécifiant un nom de domaine ou une adresse IP suivi du port. quand le port n’est pas spécifié le port 80 est pris par défaut.
– la requête : Le client envoi une requête en une seule ligne ASCII commençant par le mot GET (appelé METHOD) suivi d’espace suivi de l’adresse du document (qu’on appelle URL) terminée par les deux caractères CR et LF (retour chariot retour à la ligne)
– la réponse : La réponse du serveur à une requête GET est un document HTML.
– la fermeture de connexion : Le serveur termine la connexion après avoir délivré le document HTML.

Le Web actuel

   Au début de l’année 1996, le trafic Internet est déjà chargé par les applications Web malgré que l’Internet n’est encore qu’à ses balbutiements. De 1996 à 1999, le nombre des utilisateurs va connaitre un vraie rebond, et le W3C a décidé d’anticiper le Web que nous connaissons actuellement. La multiplication des équipements supportant le Web, le déploiement à très grand échelle des technologies d’accès à Internet de plus en plus rapides ont soutenu le travail de faire évoluer les normes Web. En effet, HTTP 1.0 montre des limites en termes de cache, de gestion des connexions TCP, et des proxies. Il faut alors le moderniser et HTTP 1.1 arrive en 1999 (RFC2616 mise à jour dans la RFC2817 puis rendue obsolète par les RFC7230…RFC7235) entièrement rétro-compatible avec HTTP 1.0 : si un en-tête n’est pas compris par l’une des deux parties (client/serveur), il doit alors être ignoré. HTTP 1.1 est la version la plus courante dans le Web d’aujourd’hui (année 2016). Elle prévoyait des mécanismes plus avancées de gestion de la connexion TCP (Pipelining et persistance de connexion) en réutilisant la même connexion TCP pour plusieurs requêtes. Ces mécanismes sont assurés par des en-têtes (Connection, Content-lenght, Chunked) sans toucher à la pile TCP au niveau du noyau. D’autres fonctionnalités telles que la négociation et la compression du contenu, la gestion des relais, l’amélioration du cache et le statut de la réponse ont été spécifiés dès la première rédaction de la RFC2616.

Caractéristiques d’une taxonomie

   Avant d’examiner les taxonomies existantes, il est important de définir ce qu’est une bonne taxonomie. Un certain nombre de critères ont été repris par Lough et Hansmann [10], [11]. Une taxonomie doit être :
1. approuvée [12] : la taxonomie doit être structurée et doit se baser sur d’anciens travaux qui sont approuvés
2. compréhensible [12] : la taxonomie fournit des informations claires et concises pouvant être comprises par les experts ainsi que par les personnes qui ne sont pas du domaine.
3. exhaustive [12][13] : Pour qu’une taxonomie soit exhaustive, elle doit tenir compte de toutes les attaques possibles et fournir des catégories bien définies. Bien qu’il soit difficile de prouver l’exhaustivité d’une taxonomie, elle peut être justifiée par une catégorisation réussie des attaques actuelles.
4. déterministe [14] : la procédure de classification doit être clairement définie. Mutuellement exclusive [12][13] : chaque attaque ne peut être classée que dans une seule catégorie, ce qui évite le chevauchement.
5. reproductible [12][14] : la classification d’attaques doit être reproductible.
6. conforme avec les standards [13] : la terminologie utilisée dans la taxonomie doit être conforme avec les connaissances antérieures et au standards de sécurité.
7. ayant des termes bien définis / critère clair [15] : Il faut que les termes utilisés ne prêtent pas à confusion.
8. non ambigüe [12][13] : Chaque catégorie de la taxonomie doit être clairement définie afin qu’il n’y ait aucune ambigüité.
9. utile [12][13] : Une taxonomie utile pourra être exploitable dans les différents contextes de son utilisation.

Taxonomie de Alvarez et Petrovic (2003)

   Alvarez et Petrovic ont analysé et classé les attaques Web. Leur but était d’extraire des informations utiles aux développeurs d’applications pour construire des systèmes plus sûrs. Ils incluent l’extraction de l’information pour prédire la source de vulnérabilités. L’hypothèse centrale est que l’étude des attaques connues et les vulnérabilités peuvent nous éclairer sur la construction de nouveaux systèmes qui seront débarrassés de ces erreurs. Alvarez et Petrovic ont développé une taxonomie multidimensionnelle avec chaque dimension représentant une caractéristique particulière de l’attaque. Ceci est similaire à la classification de Mirkovic et Reiher et a également une classification horizontale. Cela signifie que les attaques sont classées en fonction de caractéristiques disjointes. La taxonomie suit la règle suivante : « Chaque point d’entrée a une vulnérabilité qui menace un service exploité par une action à l’aide d’une entrée contre une cible avec une certaine ampleur obtenir des privilèges. » Les points d’entrée, les vulnérabilités, les entrées, et les objectifs mentionnés sont spécifiques à des attaques Web. La catégorie des services menacés, qui inclut l’authentification, l’autorisation, la confidentialité, l’intégrité, la disponibilité et l’audit, peut aussi être considérée comme le résultat final de l’attaque. Une attaque conduit toujours à une compromission de l’un des principaux services de sécurité ou des propriétés du système Cette classification est utile pour capturer des informations sur les attaques Web et peut aider les développeurs à créer des applications plus sûres. La principale limitation est que c’est une taxonomie horizontale ; les principales caractéristiques d’une attaque doivent considérées les menaces dans une taxonomie hiérarchique.

Les attaques du coté client

   Un client Web peut être un humain utilisant un navigateur Web installé sur une machine fixe ou mobile, il peut être aussi un robot logiciel (Bot) qui explore l’application Web d’une manière autonome ou semi-autonome pour de bonnes ou de mauvaises intentions. Dans cette analyse, les menaces étudiées portent uniquement la première classe des clients Web. Dans le chapitre 1, nous avons présenté des attaques visant les applications Web mais qui impactent les clients Web. Le XSS et CSRF sont les deux classes d’attaques qui exploitent le manque de validation des entrées des applications Web pour s’attaquer aux clients. Malheureusement, ce ne sont pas les seules menaces qui visent ces derniers. Un navigateur Web évolue dans un environnement non sécuritaire et exposé continuellement aux tentatives des attaquants pour le corrompre. Cette corruption peut venir de son propre utilisateur humain d’une manière intentionnelle. Elle peut aussi venir de son système d’exploitation ou des logiciels qui assurent les services de communication.
– L’ingénierie sociale est l’art de manipuler un utilisateur (humain) pour lui dérober des informations confidentielles telles que les données d’authentification, les données de paiement, etc. Le vecteur d’attaque est généralement un e-mail de hameçonnage (fishing) ou les appels téléphoniques (l’arnaque au PDG).
– Dans un explorateur Web, il est possible qu’un malware ou un utilisateur non averti, réussissent à installer un Greffon (Plug-in) malveillant dont le rôle serait de compromettre la confidentialité des échanges. Ce programme se greffe à l’intérieur de l’explorateur Web, ce qui lui permet d’écouter, éventuellement de modifier, les données avant leur chiffrement par le protocole SSL/TLS.
– L’explorateur Web est aussi exposé à des menaces par la manipulation du code source des applications Web. Ce code est composé généralement de l’HTML, de JavaScript et de CSS. Le javaScript est embarqué dans du code HTML pour être interprété par l’exportateur Web. Il peut notamment interagir avec le DOM (Document Object Model) des pages Web en vue de réaliser des fonctions spécifiques telles que le changement de couleurs, la taille du texte…etc. Cette interaction peut aller plus loin, jusqu’à la demande d’un cookie de session (d’authentification) par une entité tierce. Des sorties non « nettoyées » d’une application Web peuvent contenir du javaScript injecté et contrôlé par un attaquant. Ce code sera interprété et exécuté par l’explorateur, ce qui permet en effet, de voler des cookies ou de réaliser des actions malveillantes à l’insu des utilisateurs d’une application Web compromise.
– La compromission du cache ARP est sans doute la menace la plus dangereuse pour les clients. Cette compromission permet à un attaquant d’intercepter et de modifier toutes les requêtes et les réponses des clients affectés par cette attaque. Cette attaque est connue sous le nom de l’Homme au Milieu (Man In the Middle MITM) et permet aussi entre autres, de corrompre le DNS, de modifier les en-têtes des paquets IP (adresse IP et ports TCP).
– La mémoire cache du DNS (Domaine Name Service) d’un OS est utilisée pour accélérer les résolutions d’adresses IP par l’explorateur. Une fausse association (adresse IP – Nom de domaine) conduit à la redirection des requêtes des utilisateurs vers de faux vrais sites contrôlés par un attaquant. L’objectif de ce détournement est généralement le vol des identifiants et des mots de passe des clients.
– Le problème avec l’attaque de l’homme au milieu est que l’attaquant peut modifier n’importe quelle donnée des trames envoyées et reçues par les victimes. Cette modification peut concerner aussi en-têtes TCP/IP, il est ainsi possible de modifier les adresses IP et les ports TCP pour réaliser des redirections des requêtes et des réponses  HTTP vers et depuis des sites de phishing contrôlés par l’attaquant. L’absence d’un mécanisme de validation des adresses IP et des ports TCP au niveau local peut donc permettre ce genre d’attaques.

Techniques de détection par anomalie

   Différentes approches de modélisation du comportement existent ([28]), Nous pouvons résumé le schéma général de ces approches dans trois principales phases) :
– paramétrage : Dans cette phase, les différentes observations du système cible sont représentés sous forme de paramètres à prendre en considération pendant la construction du modèle.
– phase d’entrainement : Le comportement normal (éventuellement anormal) est spécifié et un modèle issu de cette spécification est construit.
– phase de détection : Une fois le modèle construit, il est comparé avec les données observées. En fonction d’un seuil, le modèle décide de l’état du système, et une alerte est générée un cas d’état anormal. Certaines travaux [29] décomposent les modèles comportementaux en trois classes : Statistiques, à base de connaissances et par apprentissage automatique. La première catégorie des modèles statistiques utilise une représentation aléatoire du système cible, tan disque la modélisation à base de connaissance essaye de capturer le comportement voulu à travers les spécifications du système en temps normal (l’état des protocoles, le volume du trafic, etc). La troisième catégorie permet l’établissement d’un modèle de classification permettant de discriminer en sortie les comportements normaux ou anormaux. Deux aspects clés permettant l’évaluation et la comparaison des performances des trois approches. Ceux-ci sont la précision du processus de détection et le coût lié à ce processus. Sans sous-estimer l’importance du coût, en termes calculatoire, le paramètre de la précision de détection est souvent déterminant dans le choix du modèle. Quatre situations existent dans ce contexte, correspondant à la relation entre le résultat de la détection pour un événement analysé (« normal » contre « attaque ») et sa nature réelle (« légitime » contre « . « malicieux »). Ces quatre situations se résument ainsi :
– vrai positif : si l’événement normal en entrée est correctement classifié à la sortie du modèle (« normal » classé « légitime »),
– faux positif : si l’événement normal en entrée est incorrectement classifié à la sortie du modèle (« normal » classé « malicieux »),
– vrai négatif : si l’événement attaque en entrée est correctement classifié à la sortie du modèle (« attaque » classé « malicieux »),
– faux négatif : si l’événement attaque en entrée est incorrectement classifié à la sortie du modèle (« attaque » classé « légitime »).
Notons que la précision du modèle de détection est calculée à partir de deux situation clés : le taux de faux positifs et le taux de faux négatifs. Cette dernière est plus dévastatrice que la première, car un système peut tolérer qu’il y ait des erreurs de classifications d’entrée légitimes qu’il peut résoudre par des règles d’exception, mais ne peut tolérer qu’il y ait des attaques non détectées.

Table des matières

Introduction
1 Le Web : architecture et problèmes de sécurité 
1.1 Introduction
1.2 Architecture et protocole
1.2.1 Les débuts du Web
1.2.2 Le Web actuel
1.2.3 Les perspectives du Web
1.3 Problèmes de sécurité liés aux applications Web 
1.3.1 Code source non sécurisé : le talon d’Achille du Web
1.3.2 Menaces sur les entrées des applications Web
1.3.2.1 Injection de code exécutable du côté serveur
1.3.2.2 Injection de code exécutable du côté client
1.3.3 Solutions de filtrage Web et problèmes de contournement des signatures
1.3.4 Techniques furtives d’évasion aux systèmes de filtrage
1.3.4.1 Variation de la casse (MAJUSCULE-minuscule)
1.3.4.2 Espacement
1.3.4.3 Concaténation des chaines de caractères
1.3.4.4 Encapsulation
1.3.4.5 Commentaires
1.3.4.6 Encodage d’URL
1.3.4.7 Double encodage de l’URL
1.4 Conclusion 
2 Classification des attaques : analyse et contribution 
2.1 Analyse des classifications des attaques 
2.1.1 Caractéristiques d’une taxonomie
2.1.2 État de l’art des taxonomies d’attaques
2.1.2.1 Taxonomie de Bisbet et Hollingworth
2.1.2.2 Taxonomie de Howard et Longstaff (1998)
2.1.2.3 Taxonomie de Lough (2001)
2.1.2.4 Taxonomie de Alvarez et Petrovic (2003)
2.1.2.5 Taxonomie de Hansmann et Hunt (2005)
2.1.2.6 Taxonomie de Gad El Rab et Al. (2007)
2.1.2.7 Taxonomie de Chang et Chua (2011)
2.1.2.8 Taxonomie de Simmons et al. (2011)
2.1.3 État de l’art des classifications institutionnelles des attaques
2.1.3.1 Taxonomie DARPA (2000)
2.1.3.2 Taxonomie du US-CERT
2.1.3.3 Taxonomie WASC (2010)
2.1.3.4 Taxonomie du MITRE CAPEC
2.1.3.5 Classification du OWASP
2.2 Une classification orientée entrées des Applications Web
2.3 Les attaques du coté client 
2.4 Les attaques du coté serveur
2.5 Conclusion
3 Solutions de détection des attaques Web : Étude et analyse 
3.1 Introduction
3.1.0.6 Positionnement des travaux
3.2 Modèles de détection comportementaux
3.2.1 Techniques de détection par anomalie
3.2.1.1 Approches statistiques
3.2.1.2 Approches basées sur la connaissance
3.2.1.3 Approches par apprentissage automatique
3.2.2 Systèmes de détection comportementaux et hybrides existants
3.2.2.1 Détecteurs non académiques
3.2.2.2 Systèmes de détection issus de la recherche
3.2.3 Problématique et défis
3.2.3.1 Évaluation des systèmes de détection comportementaux
3.2.4 Positionnement des travaux
3.3 Conclusion
4 Définition et conception d’une solution de détection des attaques sur les applications Web 
4.1 Introduction
4.2 Modèle hybride de filtrage applicatif : Architecture 
4.2.1 Positionnement des travaux
4.2.2 Modèle architecturale Hybride : Le grand schéma
4.2.3 Algorithme du système de détection Hybride
4.2.4 Le disséqueur du protocole HTTP
4.2.4.1 Dissection suivant la taxonomie des entrées des Applications Web
4.2.4.2 Dissection suivant la politique de filtrage
4.2.5 Le moteur d’inspection par signature
4.2.6 Le classifieur automatique par apprentissage supervisé
4.3 Classification par apprentissage automatique 
4.3.1 Les données d’apprentissage supervisé
4.3.1.1 Le vecteur des caractéristiques
4.3.2 Choix du modèle de classification
4.3.3 Modèle Bayésien naïf
4.3.3.1 Distribution de Bernoulli
4.3.3.2 Représentation des entrées d’une requête HTTP
4.3.3.3 Classification
4.3.3.4 Rapport entre les deux erreurs
4.3.4 Classification suivant le modèle Bayésien Multinomiale
4.3.5 Distribution Multinomiale
4.3.5.1 Représentation d’une entrée HTTP
4.3.5.2 Classification
4.3.6 Méthodologie et métriques d’évaluation
4.4 Implémentation, résultats et évaluation des performances 
4.4.1 Le disséqueur HTTP
4.4.1.1 Réduction de la complexité algorithmique
4.4.2 La classifieur par apprentissage automatique
4.4.2.1 Création du premier jeux de données d’apprentissage
4.4.2.2 Mesure de la performance du modèle de classification
4.4.2.3 Le coût du taux de faux négatif par l’approche TCR
4.4.2.4 Le TCR par la méthode Bayésienne multi-nomiale
4.4.3 Conclusion
5 Génération des données d’apprentissage et optimisation des performances du classifieur 
5.1 Problématique
5.2 Plateforme de génération des données d’apprentissage
5.3 Extraction et normalisation des données d’apprentissage
5.3.1 Normalisation des données d’apprentissage
5.3.2 Sélection des caractéristiques
5.3.2.1 Fonctionnement des méthodes de sélection des caractéristiques
5.4 Résultats et analyse des performances
5.4.1 Extraction des caractéristiques
5.4.2 Étude comparative des algorithmes de classification
5.4.3 Analyse des résultats
5.5 Capacité de mise à l’échelle
5.5.1 Impacte des faux positifs
5.5.2 Impacte des faux négatifs
5.5.3 Complexité des algorithmes de classification
5.6 Conclusion 
6 Conclusion générale et perspectives 
6.1 Conclusion 
6.2 Perspectives 
Bibliographie

Télécharger le rapport complet