Vulnérabilité des services d'authentification web

Les usagers d’Internet sont confrontés à un nombre croissant d’applications web nécessitant de s’authentifier. Cette authentification permet de s’assurer que l’utilisateur est bien la personne qu'il prétend être mais aussi de lui fournir des informations personnalisées en fonction de son profil et des données personnelles qu’il transmet. Elle est donc sujette à de nombreuses attaques de la part de personnes malveillantes qui souhaitent en exploiter toutes ses vulnérabilités. L’exploitation de ces failles peut être utilisée pour compromettre les services d’authentification web, même les plus forts et les plus connus, que ce soit par mots de passe, cookies d'authentification, ou avec l'utilisation de SSL[1]^,[Note 1].

L'authentification HTTP[Note 2] permet de s'identifier auprès d'un serveur HTTP à l’aide d’un nom d’utilisateur et d’un mot de passe. Il existe deux méthodes : la méthode Basic et la méthode Digest.

Cette méthode est la plus simple mais également la moins sécurisée. L'utilisateur doit fournir un nom d'utilisateur et un mot de passe pour s'authentifier. Le nom d'utilisateur et le mot de passe sont concaténés avec deux points et le tout est encodé en base 64[2]. Il est donc très facile de décoder les données et d'obtenir les informations d'identification. Cette méthode est donc très vulnérable aux attaques par écoute. Il est possible de diminuer les risques par l'utilisation du protocole SSL, qui va envoyer les données sous forme chiffrée. Toutefois, cette méthode reste vulnérable à de nombreuses attaques côté client, mais aussi à l'attaque de l'homme du milieu et également aux attaques par brute force[3].

L'authentification Digest a été conçue comme une amélioration de l'authentification HTTP de base. L'une des principales améliorations est que les données ne sont pas transmises en clair mais sont transmises à l'aide d'un message digeste chiffré[4]. Si cette méthode est moins vulnérable aux attaques par écoute, elle le reste encore aux attaques par rejeu. En effet, si un attaquant est en mesure de rejouer le message digeste chiffré alors le serveur lui donnera l’accès[5].

Toutefois, il arrive que le nonce fournit par le serveur contienne un timestamp. Ceci permet au serveur d'en vérifier la valeur lors de l'authentification : si la valeur du nonce est dépassée, alors la demande du client est rejetée[6].

Une autre menace répandue est connue par le terme hameçonnage[Note 3]. Elle consiste à employer diverses techniques pour récolter les informations d’un utilisateur. Cette collecte d'informations illégales peut être réalisée par plusieurs méthodes mais la plus répandue est le déploiement d’un faux site en trompant l'utilisateur sur sa légitimité. Pour être réalisée, l’attaquant imite un site et son nom de domaine. Puis il transmet ce site, quasi semblable au site légitime, à la victime. L'utilisateur tente donc de s'identifier au sein du site contrefait, tout en pensant être sur le site légitime. Et comme avec le protocole HTTP, les mots de passe sont transmis en clair, l’attaquant peut les récupérer. La capacité des utilisateurs à identifier de manière fiable la légitimité d'un site Web est donc essentielle[7].

Ces techniques d’attaques sont devenues de plus en plus sophistiquées. Certains hameçonneurs vont jusqu'à faire suivre les données jusqu'au site authentique afin de voler ou détourner la session de la victime. Prenons l’exemple d’une victime qui transmet les données de son compte bancaire pour un transfert d’argent : l’attaquant peut modifier la requête pour rediriger le transfert sur son propre compte. Une façon de se prémunir est d’utiliser l’authentification mutuelle, également appelée authentification à double sens. Avec ce procédé, les deux entités doivent s’identifier mutuellement avant de pouvoir communiquer : le client authentifie le serveur et vice versa. L’utilisateur s’assure donc de bien communiquer avec le serveur légitime et réciproquement le serveur s’assure que l’utilisateur est là dans un but légitime [8].

Une variante de l'hameçonnage est le dévoiement[Note 4]^,[9]. Ce type d’attaque vise à pratiquer l'hameçonnage par la redirection de l'utilisateur, grâce au DNS[Note 5], sur un serveur contrôlé par l’attaquant. Pour mener cette attaque, l’attaquant peut, par exemple, fournir un document web contenant un code malveillant à sa victime, puis exploiter la vulnérabilité du navigateur à gérer le DNS et forcer le navigateur de la victime à se connecter au serveur. Une fois l’utilisateur authentifié auprès du serveur, l’attaquant utilise le code malveillant pour détourner la session de la victime authentifiée [10].

Les cookies sont le moyen principal pour les applications web d’authentifier les requêtes HTTP et de maintenir la connexion avec le client. Ils relèvent donc d’un grand intérêt pour les pirates. Un protocole de cookie sécurisé devrait donc être en mesure de proposer les quatre services suivant : l'authentification, la confidentialité, l’intégrité et la non-duplication[11].

Le détournement de cookie est un procédé par lequel le pirate va obtenir un accès non autorisé à des informations confidentielles. Pour cela, il va voler les cookies qui contiennent les informations nécessaires pour authentifier un utilisateur à un serveur web distant. Il suffit juste que la valeur du cookie existe dans la requête pour être authentifié auprès du serveur. Dès lors, n’importe quelle personne possédant la valeur du cookie est en mesure de s’authentifier avec l’identité de l’utilisateur. Ce détournement peut être effectué par le pirate en utilisant un ordinateur entre le nœud et le serveur ou en récupérant directement les cookies stockés sur l'ordinateur de l'utilisateur. Par défaut, la valeur du cookie est envoyée en clair, chaque partie ayant accès au réseau peut donc renifler la valeur [12]. Alors que SSL/TLS[Note 6] protège contre cette menace, de nombreux sites ne protègent que la page de connexion avec SSL/TLS puis reviennent à du HTTP ce qui revient à laisser visible la valeur du cookie [13].

Toutefois, même avec l’existence d’une connexion SSL/TLS, le cookie est lisible par défaut avec JavaScript via la propriété document.cookie​. De ce fait, l’utilisation d’un Cross-site Scripting (XSS) permet quand même au pirate d’obtenir la valeur du cookie[14]. Pour contrer cette menace, les éditeurs de navigateurs ont introduit le HTTPonly-flag[15] qui permet de cacher la valeur du cookie depuis JavaScript[16].

Principe d'une attaque par fixation de session

L’attaque par fixation de session est une attaque proche du vol de session. Cette attaque permet à une personne mal intentionnée de déterminer l'identifiant de session d'une autre personne. En connaissant le SID[Note 7] d’un utilisateur, il est possible de l’utiliser et de récupérer sa session pour soi. Cette attaque repose sur le fait que, lorsqu’un utilisateur s’authentifie, un nouveau SID ne lui est pas attribué, ce qui rend possible l’utilisation de son SID. Avec cette attaque, l’attaquant fixe le SID de l’utilisateur, avant même que celui-ci n’ouvre une session sur le serveur cible. Cette méthode évite ainsi à l’attaquant de devoir récupérer par la suite le SID de l’utilisateur. Pour ce faire, l’attaquant ouvre une session sur le serveur et obtient un SID valide. Puis, il transmet ce dernier à sa victime, à l’aide d’un lien, par exemple au travers d’un email. La victime clique sur le lien et se connecte au serveur. Une fois la connexion établie, l’attaquant peut envoyer de nouvelles requêtes aux serveurs et comme il possède le même SID, il a accès aux données. La session a été détournée[17].

L’objet de cette attaque est de forcer des utilisateurs à exécuter une ou plusieurs requêtes non désirées sur un site donné. L’utilisateur devient donc complice d’une attaque sans même en avoir conscience [18]. Cette dernière étant actionnée par l'utilisateur, un grand nombre de systèmes d'authentification sont contournés. Pour cette attaque, l’attaquant falsifie une requête HTTP qui pointe sur une action précise interne au site (souvent par le biais d’une URL[Note 9], ou d’un formulaire). Puis, il se charge de la transmettre à la victime afin que celle-ci l'exécute sans en avoir conscience. L'intérêt de cette attaque et de pouvoir obtenir les droits de la victime pour réaliser une action dont l'attaquant ne possède pas l’autorisation[19].

L'attaque proposée par Marlinspike contre SSL.

Transport Layer Security (TLS), aussi connu sous le nom précédent de Secure Sockets Layer (SSL), est un protocole qui a pour objectif de fournir la confidentialité et l'intégrité des données entre deux applications en communication[20]. Son utilisation conjointe avec le protocole HTTP permet de se protéger contre certaines attaques en chiffrant les communications et les authentifications clients/serveurs. HTTPS[Note 10] permet donc de transférer des données par le port 443 en utilisant un chiffrement asymétrique[21]. Toutefois même si ce protocole est plus sécurisé, il peut également être compromis de différentes façons. Par exemple, Burkhoder a proposé une attaque qui consiste à renifler les données HTTPS en utilisant un faux certificat [22].

On peut également mentionner l'attaque qui consiste à ce qu’une personne malveillante se mette au milieu de la conversation et se fasse passer pour le serveur, dite attaque de l'homme du milieu. De même, l'attaque proposée en 2009 par Moxie Marlinspike est difficilement repérable par la victime car elle peut être menée sans avertissement de la part du navigateur. Les navigateurs web (tels que Chrome, IE, Firefox, Opera, Safari) émettent des messages d’avertissement sérieux face à un faux certificat SSL. Pour éviter ces messages, Marlinspike a proposé une nouvelle technique d'examen du SSL qui consiste à intercepter la communication, puis détourner le trafic HTTPS sur un réseau et le rediriger vers le navigateur client, les communications dans ce cas peuvent donc être espionnées puisqu’il n’y a plus de chiffrement et dans ce cas l’attaque peut se faire sans avertissement de la part du navigateur[23]^,[24].

La concurrence sur le marché des navigateurs motive les développeurs à en faire plus qu’un simple outil pour la visualisation des pages web. La norme ISO 9126[25] définit la qualité des fonctionnalités proposés par ces navigateurs. L’une d’elles consiste à la mise en place d’un système de gestion de mots de passe.

Ce besoin d'authentification provient du fait que de nombreuses applications web implémentent des sessions sécurisées qui demandent à l’utilisateur de s’authentifier à l’aide d’un nom d’utilisateur et d’un mot de passe. Ces méthodes obligent donc l’utilisateur à connaître ses multiples identifiants suivant chaque site. Face à cette problématique, les développeurs de navigateurs ont donc mis en place un système de gestion de mots de passe facilitant l’authentification de l’utilisateur. Ce système demande simplement que l'utilisateur se souvienne d'un mot de passe maître qui sera utilisé pour déchiffrer les autres qui se trouvent dans la base de données du gestionnaire de mots de passe[26].

L'utilisation d'un gestionnaire de mots de passe a un autre avantage. L’adresse URL, ou au moins le nom de domaine, est stockée à côté du mot de passe correspondant. Elle permet au navigateur de remplir automatiquement le formulaire de connexion. Si l'utilisateur est dirigé vers un site web malveillant qui est conçu pour ressembler à l'identique au site légitime qu'il attend, alors le gestionnaire de mots de passe ne pourra pas autocompléter les champs du formulaire et connecter l’utilisateur. Ainsi, les utilisateurs qui utilisent un gestionnaire de mots de passe sont moins sensibles aux typosquattages [27] et aux attaques par hameçonnage.

Mozilla Firefox stocke ses données de connexion dans deux fichiers différents. Le premier fichier key3.db​ stocke le mot de passe principal pour accéder à la base de données, le second signons.sqlite​ stocke les mots de passe et les adresses des sites dans une base SQLite. Les identifiants sont chiffrés avec le mot de passe maître du fichier key3.db​ et encodés en Base64. Si l'utilisateur ne fournit pas de mot de passe maître alors Firefox utilise une valeur par défaut pour chiffrer les données. Quant aux adresses URL, elles sont toujours stockées en clair avec ou sans mot de passe maître[28].

Si un attaquant souhaite déchiffrer les données de signons.sqlite​, il doit d'abord obtenir le mot de passe principal stocké dans key3.db​. Pour cela, différentes méthodes sont possibles : les attaques par brute force, soit en générant tous les mots de passe possibles à partir d'un vocabulaire donné, soit en utilisant un dictionnaire.

La sûreté des différents mots de passe repose donc sur la robustesse[29] du mot de passe principal.

Mozilla Firefox stocke aussi d’autres données non chiffrées, comme le nom des champs de formulaire renseignés avec le mot de passe et le nom d’utilisateur. Le problème est que si un attaquant arrive à obtenir l’accès à la base de données, il peut récolter une quantité d’informations considérable. Il peut par exemple récupérer les adresses des sites Internet où la victime a des mots de passe enregistrés et monter une attaque par hameçonnage en s'appuyant sur les informations récoltées.

Google Chrome stocke les noms d'utilisateur et mots de passe, ainsi que d'autres données personnelles dans un fichier de base de données SQLite dans le répertoire du profil utilisateur. Seul le mot de mot de passe est chiffré et les autres données sont accessibles facilement. De ce fait, n'importe quelle personne ayant accès à la base de données peut en lire le contenu et y apporter facilement des modifications. L'utilisateur ne peut donc pas se fier à la confidentialité et l'intégrité de ses données. De même, Google Chrome ne propose pas de mot de passe principal comme Firefox. Mais il est possible d'installer une extension qui ajoute cette fonctionnalité et permet d'ajouter une couche de sécurité[30].

Il est également possible de stocker les identifiants sur les serveurs de Google pour permettre la synchronisation avec les différents appareils. Les pages de support de Chrome affirment que les mots de passe sont stockés sous forme chiffrée sur les serveurs de Google [31].

Internet Explorer stocke les noms d'utilisateur et mots de passe dans le registre. Chaque enregistrement est stocké comme une entrée de registre distincte et est chiffré en utilisant les informations de connexion du système. Internet Explorer stocke l'URL de la page en utilisant une fonction de hachage SHA1[32]. L'URL et le mot de passe de session sont ensuite utilisés comme clés avec un algorithme de chiffrement fourni par Windows pour chiffrer le mot de passe et le nom d’utilisateur. La sécurité du gestionnaire de mot de passe sous Internet Explorer dépend donc également de la robustesse du mot de passe du compte utilisateur[33].

Attaque contre les navigateurs MITB (Man-in-the-Browser)

Les attaques sur les flux de données entre un client et un serveur sont devenues plus sophistiquées. Désormais, les attaques visent plutôt à contourner la protection de sécurité utilisée par les logiciels du client. MITB[Note 11] est un type d’attaque qui consiste à infiltrer un logiciel client tel que le navigateur d’une victime, ce qui permet de lui voler des informations sensibles ou de manipuler les transactions entre le client et le navigateur. L’attaque MITB est conçue pour manipuler les informations entre le client et le navigateur. Ce type d’attaque est généralement compliqué à détecter en raison de sa nature qui consiste à attacher secrètement un code malveillant dans une extension du navigateur. L'attaquant attend ensuite que l’utilisateur visite certains sites Internet pour enregistrer les informations saisies et les manipule avant de les transmettre au serveur[34].