Vulnérabilité des services d'authentification web
From Wikipedia, the free encyclopedia
La vulnérabilité des services d'authentification web correspond aux faiblesses des protocoles d'authentification du web.
Les attaques contre les services d'authentification HTTP et HTTPS sont de plus en plus sophistiquées et touchent désormais les navigateurs. Pour faire face à cela, les développeurs ont décidé d'augmenter la sécurité de leur logiciel en proposant de nouvelles fonctionnalités, par exemple, un système de gestion de mot de passe.
Introduction aux protocoles d'authentification
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].
Authentification HTTP
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.
HTTP Basic
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].
HTTP Digest
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].
Attaque par hameçonnage
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].
Authentification par cookies
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].
Vol de cookies
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].
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].
Injections de requêtes illégitimes par rebond
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],[Note 8]. 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].
Authentification HTTPS
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].
