Notre dépendance aux services qu’offre le Web est de plus en plus importante. Nous utilisons des applications Web pour acheter en ligne, pour se déplacer, pour communiquer, pour se divertir, etc. Cet engouement pour le Web a créé une véritable économie numérique qui prend de l’empileur d’année en année. En conséquence, des attaques, avec des motivations diverses et variées, se sont développées et sont devenues de plus en plus sophistiquées. Elles ciblent principalement les données liées à des activités économiques. Ainsi, elles portent un préjudice important au fonctionnement global des systèmes d’information.

Cependant, plusieurs efforts sont consentis par une communauté de plus en plus importante au tour de la sécurité des applications Web. Cette communauté a pris conscience des risques liés à l’exposition des systèmes d’information sur Internet. Par conséquent, elle contribue activement par des productions sur un plan informationnel (classification et recensement des attaques, publications des vulnérabilités, bonnes pratiques, …), mais aussi par des solutions opérationnelles (Systèmes de Détection d’intrusion, Pre-feux applicatifs, anti-malwares,…) pour atténuer l’impact des attaques contre les applications Web. Ces solutions sont basées sur des approches bien éprouvées, notamment, dans des systèmes de détection d’intrusion. Toutefois, des problèmes persistent quand il s’agit de la détection des attaques sur les applications Web. En effet, la diversité des attaques, qui est en grande partie liée à la richesse de la sémantique applicative toujours naissante, a augmenté considérablement le nombre d’obstacles à contourner pour résoudre ces problèmes.

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).

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.

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.

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.