Le deuxième article de cette série est dédié aux failles de type hijacking (classées n°2 à l’Owasp Top 10). Ce terme ne vous parle peut-être pas, ou peut-être ne voyez vous pas exactement en quoi cette vulnérabilité consiste, mais le principe est très simple à comprendre. Il s’agit de la possibilité pour un pirate d’utiliser l’identité d’autres personnes sur votre site Internet.
Si l’on regarde les statistiques sur les vulnérabilités web, on se rend compte que cette faille est très largement répandue, bonne raison donc pour s’y intéresser, aussi bien pour les pirates que pour les équipes de développements. En terme d’exploitabilité, cette faille se situe dans la moyenne: la détecter n’est pas extrêmement facile (mais loin d’être difficile), et utiliser la faille une fois cernée est relativement facile.
L’impact d’une telle faille dépendra entièrement de ce que votre application web offre comme possibilités à ses utilisateurs. Une fois exploitée, c’est à dire une fois que l’attaquant a pris possession de l’identité d’une victime, toutes les fonctionnalités pouvant être utilisées par la victime seront désormais accessibles au pirate.

Si l’on prend l’exemple d’un site e-commerce, le pirate pourra passer des commandes sous l’identité de la victime. Pour peu que les données bancaires aient été enregistrées lors d’une commande ultérieure, ou encore que l’adresse de livraison soit modifiable sans re-authentification, le travail est grandement facilité pour le hacker.
Pour vous rendre compte de l’impact de ces failles, imaginez vous simplement donner les commandes d’un compte utilisateur sur un site X ou Y à une personne malintentionnée. Les possibilités sont illimitées.

impersonate picture

Dans quels cas un site est-il vulnérable à ce genre d’attaque?

Tout d’abord, si les éléments permettant d’authentifier un utilisateur (login / mot de passe) sont mal protégés dans le site web. Dans le cas où un pirate accède à la base de données du site, par quelque moyen que ce soit, il peut accéder à la liste des login et des mots de passe. Les bonnes pratiques veulent que les mots de passe soient correctement “hashés” ou “cryptés » dans la base, pour être inexploitables par un pirate.

La deuxième possibilité est de pouvoir deviner ou modifier les éléments d’authentification facilement. Une politique de mots de passe forte doit être mise en place afin que les utilisateurs n’utilisent pas des mots de passe trop simples à deviner. Par ailleurs, les mécanismes permettant à un utilisateur de changer de mot de passe ou de récupérer un mot de passe, s’ils sont mal pensés, permettront à un attaquant de changer ou récupérer le mot de passe à la place de l’utilisateur!

La troisième possibilité est un peu plus technique et exploite des faiblesses dans les mécanismes qui permettent au serveur du site web de se souvenir de qui vous êtes, une fois que vous vous êtes authentifié. En effet, par nature, les protocoles de communication entre le serveur et votre navigateur web ne permettent pas de se rappeler qui vous êtes. Certaines fonctionnalités doivent donc être implémentées afin de se souvenir de vous, c’est ce qu’on appelle les sessions, et le fameux Session ID. Ce Session ID, généralement stocké dans les cookies du navigateur ou dans l’URL, peut présenter plusieurs faiblesses si mal implémenté:

  • facile à deviner
  • facile à imposer à une victime (par exemple en lui fournissant un lien qui contiendra le Session ID à utiliser) et donc utilisable par le pirate
  • sans mécanisme d’expiration
  • toujours le même pour une personne donnée, au fil des visites

Nous ne rentrerons pas plus dans les détails ici, mais dans tous les cas, la connaissance de ce Session ID pour un pirate permet dans un bon nombre de cas de prendre l’identité d’une autre personne.

Enfin, si les éléments d’authentification, y compris le Session ID, sont communiqués sans cryptage sous https (c’est à dite SSL / TLS), alors ils sont potentiellement interceptables et donc utilisables par un pirate.

Comment éviter ce genre de vulnérabilités?

Il faut tout d’abord savoir que construire un mécanisme d’authentification solide en partant de zéro est assez laborieux, et difficile. D’autre part s’il n’est pas testé par de multiples personnes, il y a de fortes chances qu’il soit vulnérable à certaines attaques. Mais heureusement il existe de nombreuses briques d’authentification et de gestion d’identité prêtes à être utilisées et de confiance!
Les frameworks de développement type Microsoft .Net, ou Java, ou encore PHP, proposent de telles choses, dont il faut profiter.

Les mécanismes permettant de récupérer un mot de passe perdu ou de changer mot de passe doivent être soigneusement conçus, afin d’éviter de simples failles logiques.
Il n’existe pas de de réel standard pour ces mécanismes, d’où la grande variété de logique pouvant être rencontrées sur Internet.

Pour aller plus loin:

Owasp authentication cheat sheet
Owasp forgot password cheat sheet
Owasp session management cheat sheet

Autres articles dans cette série :