Fonctionnement global

Le fonctionnement du Web est une interaction entre un client (navigateur) et un serveur HTTP (Figure 2.8). L’environnement du client est cloisonné (« sandboxed ») à l’intérieur du navigateur (Safari, Chrome, Firefox, Edge, Internet Explorer …) et n’a pas accès facilement aux fonctionnalités du système d’exploitation. Il est cependant possible que des exceptions de sécurité puissent être acceptées par l’utilisateur pour l’utilisation des ressources locales (par exemple par des scripts Java, JavaScript ou ActiveX contenus dans un document). Le serveur, quant à lui, peut accéder à certaines fonctionnalités du système d’exploitation sur lequel il est installé tout en respectant les restrictions de privilèges. C’est-à-dire qu’il est limité aux droits accordés à l’utilisateur qui l’exécute. Figure 2.8 – Composants de l’environnement Web client-serveur Les connexions entre le navigateur et le serveur sont sans état « stateless », c’est-à-dire qu’il n’y a pas de continuité entre les échanges. Ainsi, par défaut, il n’y a pas de session de travail. Le protocole HTTP n’utilise pas non plus, par défaut, de connexions persistantes « keep-alive » pour la réalisation de plusieurs transferts d’objets [43]. Tous les échanges sont initiés par le client. Cependant, cela tend à changer avec l’adoption de HTTP/2 (Figure 2.9) et l’utilisation du Web pour des connexions bidirectionnelles (push, websockets server side events).

Il est à noter que la composition et le rendu des données sont faits par le logiciel client et nécessitent plusieurs connexions ou échanges avec le serveur afin d’obtenir tous les éléments nécessaires. Lors de l’exécution d’une requête typique, l’utilisateur saisit l’adresse désirée dans la barre de son navigateur. Le logiciel client transmet alors une requête au serveur en utilisant le protocole HTTP(S). Cette requête est composée d’un entête comprenant plusieurs éléments dont la méthode à utiliser (exemple : GET) et la ressource désirée (exemple : fichier.txt). Le serveur qui reçoit cette requête valide l’existence de la ressource, effectue l’action appropriée selon la méthode et en retourne le contenu résultant accompagné des entêtes nécessaires au respect du protocole. La documentation sur les systèmes Web, l’utilisation de serveurs HTTP(S) et le développement d’applications autant serveur que client abonde sous toutes sortes de formes; livres papiers ou numériques, vidéos, sites Internet, formations en classe ou en ligne.

Le serveur Apache HTTP

Le serveur Apache HTTP [13] de « Apache Foundation [44] » est un logiciel à code ouvert. La version la plus récente est de la série 2.4 (en date de ce document, 2.4.34). L’architecture de ce serveur a grandement évolué entre la version 1 et 2. La version 2 propose une architecture modulaire plus complète, facilitant ainsi l’intégration de nouvelles fonctionnalités. Ce serveur est disponible pour plusieurs systèmes d’exploitation, ceux des familles « Unix », « Windows » et « Mac » (OS X maintenant un Unix basé sur BSD). Le livre « The Apache Modules Book – Application Development with Apache » [45] présente bien le logiciel et la manière de développer des modules complémentaires. Le logiciel est conçu de manière modulaire et utilise des bibliothèques de composantes portables d’un système d’exploitation à un autre (Apache Portable Runtime ou APR). De plus, la chaine de traitement de l’information permet aisément d’introduire des traitements supplémentaires. Les Figure 2.10 à 2.12 extraites du livre cité ci-dessus illustrent ces faits. La Figure 2.10 illustre la structure de développement basée sur un coeur accompagné de différents modules tout basés sur l’APR. La Figure 2.11 montre le traitement linéaire des requêtes dans Apache 1.x de la réception jusqu’à la journalisation et la transmission.

La Figure 2.12 décrit le même fonctionnement pour Apache 2.x avec l’ajout d’un second axe pour la composition du document à retourner. Ces informations confirment donc qu’Apache HTTP, particulièrement en version 2.x, est un bon candidat pour la mise en place d’un module gérant la sécurité, autant en amont du traitement « Metadata Processing » qu’en aval de la génération de contenu « Output Filters ». De plus, plusieurs modules sont déjà disponibles et pourraient servir de base au projet [46]. La documentation sur le serveur Apache HTTP est relativement commune sous toutes sortes de formes; livres papiers ou numériques, vidéos, sites Internet, formations en classe ou en ligne. Cependant si l’on restreint le champ de recherche au développement proprement dit du serveur, on retrouve principalement deux ouvrages « Writing Apache Modules with Perl and C: The Apache API and mod_perl » pour les versions antérieures et « The Apache Modules Book: Application Development with Apache » pour la version 2.x. Les autres ressources se limitent à de la documentation en ligne.

Le protocole HTTP(S)

Le protocole de communication entre les logiciels clients et les serveurs est HTTP(S). Présentement, deux versions sont très répandues soit 1.1 et 2.0. Ce protocole est défini par des spécifications de l’IETF sous forme de RFC (Request For Comment) [47]. Ces 22 spécifications sont en constante révision sous la supervision du IETF HTTP Working Group [48]. Plus précisément, la version 1.1 est définie dans le RFC 2616 et la version 2 dans le RFC 7540. Ces deux versions du protocole HTTP définissent des éléments pour la sécurisation des applications Web. La plus couramment utilisée est « basic authentication » basée sur la transmission par le serveur d’une réponse avec le statut « 401 » et retour du client avec un entête d’autorisation « Authorization ». Plusieurs autres éléments tels que des entêtes supplémentaires, des statuts de réponse, l’utilisation de témoins et la transmission de paramètres peuvent également servir à implémenter une couche d’autorisation et authentification. Il faut également mentionner que le protocole HTTP, en version 1 ou 2 peut être utilisé de manière sécurisée en version HTTPS.

Le protocole est alors utilisé au travers de TLS/SSL plutôt que directement en texte clair. En effet, TLS (Transport Layer Security) et SSL (Secure Sockets Layer) sont deux protocoles cryptographiques qui fournissent à la fois l’authentification et le cryptage des données [49]. Le standard TLS créé par l’IETF est le successeur de SSL créé par Netscape [50]. Cette information est importante, car elle influence la sécurité lors de l’utilisation de « basic authentication » du protocole. Déjà en 2015 [51], des discussions avaient lieu pour déclarer la désuétude de HTTP au profit de HTTPS pour des communications plus sécuritaires à la grandeur de la toile. Les RFC de l’IETF étant la documentation officielle de ces protocoles, la recherche documentaire sur ce sujet n’a pas été plus exhaustive. Il est également important de mentionner l’ouvrage « Architectural Styles and the Design of Network-based Software Architectures » [52] par Roy Fielding dont l’extrait suivant démontre la pertinence pour l’utilisation de ces normes. « This dissertation defines a framework for understanding software architecture via architectural styles and demonstrates how styles can be used to guide the architectural design of network-based application software. A survey of architectural styles for network-based applications is used to classify styles according to the architectural properties they induce on an architecture for distributed hypermedia. I then introduce the Representational State Transfer (REST) architectural style and describe how REST has been used to guide the design and development of the architecture for the modern Web.» En effet, M. Fielding est un membre actif du développement des normes définissant le protocole HTTP et cet ouvrage permet de bien saisir les principes sous-jacents à son utilisation dans le développement d’application Web. La définition du protocole quant à elle décrit deux éléments importants que l’on voit expliqués dans la documentation sur sa sémantique. Le RFC7231 « Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content » HTTP/1.1 request and response semantics in terms of the architecture defined in [RFC7230]. »

Applications Web

L’authentification de l’utilisateur peut se faire de plusieurs manières. Le protocole HTTP inclut des fonctionnalités de base supportées par la plupart des navigateurs qui reposent sur la transmission d’un code de statut 401 et de l’entête WWW-Authenticate tel qu’illustré sur « http gallery » [54]. Les mécanismes les plus utilisés sont: Basic, Digest et NTLM (NT Lan Manager). D’autres mécanismes plus complets et complexes peuvent également être utilisés tels que: utilisation de certificats et utilisation d’un jeton (« token ») (en témoins ou en paramètre) conjointement avec une authentification directe sur le serveur ou délégation à un tiers (SSO ou Single Sign-on [55]). Presque toutes ces méthodes nécessitent une interaction avec l’utilisateur pour fournir une ou des informations (utilisateur, mot de passe, certificat …) pour confirmer son identité, due aux restrictions de l’environnement du navigateur, qui rend inaccessible l’identité de l’utilisateur sur le système pour une transmission directe sauf dans des cas comme l’utilisation de NTLM/Kerberos sur des postes Windows avec des sessions reliées à un domaine. Kerberos [56] est un protocole pour l’échange de manière sécurisée des authentifications.

Une implémentation gratuite est fournie par le MIT (Massachusetts Institute of Technology). Il est utilisé pour l’authentification dans plusieurs systèmes. Le serveur Apache fournit d’ailleurs un module pour en faire l’utilisation pour la validation des informations reçues via la Basic Authentification avec un serveur Kerberos [57]. L’utilisation de Kerberos directement entre le client (Navigateur) et le serveur implique une modification des paramètres du navigateur [58] et l’ajout de composants et/ou la modification de configuration du serveur pour supporter le mécanisme SPNEGO (Simple and Protected GSS-API Negotiation) [59, 60]. Outre quelques applications Web basées sur les technologies Microsoft (Windows, Internet Explorer, Internet Information Server) utilisant NTLM et une authentification basée sur la session de travail sur le poste client, la majorité des systèmes utilisent une identification basée sur la saisie d’informations (identifiant/mot de passe) ou l’utilisation de certificats d’identité. Les mécanismes prévus dans le protocole HTTP sont mis à contribution pour réaliser ces opérations. La validation des informations par le serveur varie grandement d’un système à un autre. Plusieurs systèmes ont une base de données interne, d’autres utilisent des informations système locales ou en réseau. D’autres délèguent même ces fonctionnalités en partie à des tiers (utilisation de SSO par exemple).