Le Web architecture et problèmes de sécurité

Les évolutions des systèmes de télécommunications et de l’informatique ont permis l’émergence de nouvelles technologies pour répondre aux besoins grandissants en termes de connectivité et de partage de données. Vers la fin des années 80s, un physicien du CERN, Tim Berner-Lee, initia le projet World Wide Web (la toile d’araignée mondiale) après avoir déjà travaillé sur le projet précurseur du Web ENQUIRE depuis le début des années 80s. L’objectif du projet WWW ou W3 était de « fournir un système d’information collaboratif, indépendamment des plateformes matériels et logiciels, et de la localisation géographique ». Le projet décrivait un paradigme englobant un fonctionnement distribué en mode client/serveur, du contenu en hypertexte et un protocole de transfert des documents hypertexte basé sur des URLs.

Le Web est un système distribué basé sur le modèle client/serveur ouvert, où les ressources se trouvent du côté du serveur et les utilisateurs pouvant les exploiter à travers des clients qu’on appelle navigateurs. La conception de ce modèle est basée sur le principe des documents en hypertexte inter-connectées par des hyperliens. Pour la description de ces documents, il a fallu développer un nouveau langage qui structure la sémantique du contenu par un système de balisage. Le langage HTML (Hypertxt Markup Languge), descendant directement du langage SGML, permet la création et la mise une forme des documents qu’on appelle pages Web. Ces pages sont échangées entre le client et le serveur par le bais d’un système de requête/réponse appelé protocole HTTP (Hypertext Transfert Protocol).

Architecture et protocole

Le protocole HTTP est le socle principal du paradigme voulu par le consortium W3C créé par Tim Berners-Lee en 1994. Les évolutions des standards qu’a connu le Web dans le W3C et à travers les RFCs de L’IETF (Internet Engineering Task Force) portent, pour la plupart, sur le protocole HTTP. Dans la suite ce chapitre, nous considérons la version du protocole HTTP comme un indicateur pertinent de l’évolution du 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.

La première version publiée en collaboration avec l’IETF, est la version 1.0 dans la RFC1945 en mai 1996. HTTP 1.0 est la base du Web que nous connaissons aujourd’hui. Dans cette version une requête ne porte plus sur une seule ligne, mais sur plusieurs lignes qui représentent des en-têtes. Le rôle de ces en-têtes est de fournir des informations sur le client ou le serveur Web, sur le type du contenu avec le type MIME sur la gestion du cache et sur la gestion de l’authentification avec les modes Basic et Digest. Notons que la gestion de la connexion réseau était la même que celle définie dans la version 0.9. Il n’y avait pas de mécanismes de persistance de la connexion au niveau réseau, malgré l’introduction de la part de Netscape des cookie qui ont donné à un protocole sans état (HTTP) la notion de session. Le Web est devenu interactif avec la définition de la méthode POST qui permet à un client l’envoi de données vers le serveur. Les CGI (Common Gateway Interface) traitent les données des clients au moyen de langage scripts (Shell, Perl) ou en langage C, ce qui donne une dynamicité aux serveurs Web pour personnaliser les réponses en générant dynamiquement du code 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.

HTTP 1.1 a permis l’émergence de nouvelles technologies Web d’échanges, de formatage et de traitement des données du côté client et du côté serveur. Ainsi, l’avènement des appelets et des langages de scripts du côté client tels que JavaScript et VBscript, des fichiers de feuilles de style (CSS) et des langages Web interprétés (PHP, Java, ASP, Python, Perl, …), ont poussé à l’explosion de la demande et l’offre en termes de services sur Web. Actuellement, le Web est devenu une partie intégrante de notre vie, même les entreprises ont fait passer leurs systèmes d’information sur le Web.

Les perspectives du Web

La troisième version majeure de HTTP est HTTP/2. Les spécifications de cette version ont été publiées dans la RFC7540 en Mai 2015. Le HTTP/2 est le décédant du protocole SPDY qui a été développé par Google puis cédé pour être standardisé sous HTTP/2. Les améliorations apportées par cette version concernent essentiellement la sécurité et les performances sans toucher aux composantes protocolaires définies dans HTTP 1.1. Ainsi, HTTP/2 est une sous couche de HTTP 1.1 qui implémente nativement une couche TLS pour assurer la confidentialité et l’intégrité des échanges entre le client et le serveur. La gestion du pipelining a été amélioré pour éviter le phénomène du blocage lorsqu’une requête est perdue dans une connexion TCP ouverte. Le multiplexage des requêtes sur une seule connexion TCP augmente considérablement les performances globales des transactions HTTP. La compression des en-têtes a été aussi définie pour réduire au maximum la taille des échanges. Finalement, le serveur aura la possibilité de faire du PUSH (pour des notifications par exemple) sans sollicitations de la part du client à condition que la connexion TCP soit déjà établie par le client.

Problèmes de sécurité liés aux applications Web

Le paradigme d’ouverture, de distribution de l’architecture Web et de flexibilité du protocole HTTP, posent des problèmes de sécurité à tous les niveaux du modèle n tiers présenté précédemment. En effet, la richesse de la sémantique des flux métiers, la multitude des plateformes de développement et des langages, la flexibilité de certains langages et leur tolérance aux pannes, accentuent la difficulté de la maitrise du processus de sécurisation des applications Web.

Au niveau des systèmes de défense, la plupart des systèmes de détection d’intrusion et de filtrage applicatif utilisent des règles de sécurité. La majorité de ces règles sont des signatures d’attaques qui caractérisent des activités malicieuses. Le processus d’écriture une signature d’attaque demande une forte expertise et un travail considérable d’analyse et de collecte d’informations liées à une attaque : le vecteur d’attaque, la vulnérabilité exploitée, son impact…etc. Pour finalement, l’exprimer sous forme de script ou de pattern concis, généralement sous forme d’expressions régulières complexes, caractérisant d’une manière unique et pertinente une attaque. Dès lors, un problème se pose avec cette approche. Le degré de granularité d’expression de cette signature peut conduire à deux cas de divergence. Le premier cas, est une granularité trop fine qui risque de ne pas correspondre aux attaques polymorphes utilisant des techniques furtives . Le deuxième cas, est une grosse granularité où la signature est trop générale et risque de générer de fausses alertes ou de bloquer des flux légitimes.

Des travaux ont été menés sur les langages d’expression des attaques (signatures, impact, alertes) pour améliorer la précision de détection des systèmes de sécurité. Malgré les bons résultats obtenus, un effort particulier sera donné à la partie mise à jour des signatures d’attaques et cela d’une manière continue. En effet, une course sans fin a été entamée entre les systèmes de sécurité et les attaquants. Ces derniers ont le temps d’analyser les contre-mesures, de se documenter sur les cibles (environnement d’exécution, architecture, vulnérabilités connues, …) et d’essayer d’adapter l’attaque en fonction de l’ensemble des informations collectées en vue trouver un moyen d’échapper aux signatures déployées sur les systèmes de défense.

Dans cette section, nous présentons le problème de la sécurité des applications comme étant un problème de filtrage des entrées de ces dernières. Nous parlons du filtrage dans deux contextes différents. Le premier est un filtrage défini par les développeurs des applications au niveau du code source. Ce filtrage permet de contrôler les données envoyées par les clients et éviter les codes malicieux injectés par les attaquants. Le deuxième type de filtrage est déployé au niveau des systèmes de défense tels que les WAFs. Ces derniers utilisent un ensemble de règles de sécurité pour inspecter toutes les requêtes des clients et éventuellement les réponses du serveur.

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
Conclusion

Télécharger le rapport complet