Atténuer le clickjacking — à la manière DevSecOps !

Ces dernières semaines, nous avons reçu quelques signalements (via notre programme de bug bounty) indiquant que certains de nos domaines internes étaient vulnérables aux attaques par clickjacking. Bien sûr, notre site principal était protégé dès le premier jour, mais quelques petits sous-domaines ne bénéficiaient pas de cette protection. Corriger le problème était facile, mais nous voulions aller plus loin et nous assurer que tous nos points de terminaison étaient protégés, afin de ne plus avoir à nous en soucier. Voyons comment nous avons procédé.

Qu’est-ce que le clickjacking ?

D’après la définition de l’OWASP :

« Le clickjacking, également appelé « attaque par détournement d’interface », consiste pour un attaquant à utiliser plusieurs couches transparentes ou opaques afin de tromper un utilisateur et de l’amener à cliquer sur un bouton ou un lien d’une autre page, alors qu’il pense cliquer sur la page affichée au premier plan. L’attaquant « détourne » ainsi les clics destinés à sa page pour les rediriger vers une autre page, appartenant très probablement à une autre application, à un autre domaine, ou aux deux. »

Il s’agit d’une attaque particulièrement sérieuse. Le vecteur d’attaque le plus courant consiste à créer un autre site Web et à intégrer le site ciblé dans un iframe. L’attaquant peut ainsi lancer facilement une attaque par clickjacking et inciter des utilisateurs sans méfiance à cliquer sur le site malveillant.

Atténuer le clickjacking

Comme indiqué ci-dessus, le principal vecteur d’attaque repose sur les iframe. Il suffit donc d’indiquer au navigateur que notre site ne peut pas être chargé dans une iframe pour neutraliser complètement cette attaque ! Heureusement, un en-tête permet précisément de le faire : x-frame-options. Il ne nous reste qu’à définir cet en-tête, et le tour est joué !

Mais un petit problème se pose : comment savoir quels sont les points de terminaison qui comportent cet en-tête et lesquels ne l’ont pas ? Chez Snyk, nous avons un grand nombre de points de terminaison, et il est très difficile de tous les suivre. Il nous faut un outil pour nous y aider !

Présentation d’OWASP AMASS

OWASP AMASS est un outil de l’OWASP qui permet de « cartographier en profondeur la surface d’attaque et de découvrir les ressources », exactement ce dont nous avons besoin. L’une de ses fonctionnalités est l’énumération DNS : elle permet de trouver tous les enregistrements DNS d’un domaine donné. Son utilisation est très simple :

amass enum -d <domain> -o out.txt

Cette commande recherche tous les enregistrements pertinents et les écrit dans out.txt. Il ne nous reste qu’à parcourir la liste et à vérifier la présence de l’en-tête x-frame-options dans chaque enregistrement DNS. Pour cela, nous allons utiliser un outil au nom plutôt explicite : Security Headers Checkers.

Analyser les en-têtes de sécurité

Security Headers Checker est un utilitaire Python qui analyse une URL à la recherche de différents problèmes de sécurité, notamment l’absence d’en-têtes de sécurité comme x-frame-options. Il propose de nombreuses fonctionnalités intéressantes et, surtout, son fichier readme décrit clairement tous les problèmes qu’il peut détecter et explique pourquoi ils sont importants. Mais la fonctionnalité la plus utile dans notre cas est la prise en charge d’un fichier contenant une liste d’URL, comme celui généré par AMASS. Il nous suffit donc de :

python ./securityheaders/securityheaders.py out.txt --checkers HeaderMissingChecker --format json  --flatten --file ./result

Nous utilisons la sortie d’amass et limitons la vérification à HeaderMissingChecker, puisque c’est ce qui nous intéresse. L’argument suivant définit le format : j’ai choisi JSON, mais de nombreux autres formats sont également pris en charge.

Nous avons maintenant un fichier contenant toutes les URL vulnérables. Il ne nous reste qu’à utiliser une petite astuce avec JQ pour ne conserver que les URL dépourvues de l’en-tête x-frame-options, car Security Headers signale aussi de nombreux autres en-têtes intéressants. Rien de plus simple :

jq 'map(select(.header == "x-frame-options"))’ ./result/1.csv 

Oui, le fichier de sortie a le suffixe csv : c’est un bug :)

Nous avons maintenant la liste. Il ne reste plus qu’à faire le vrai travail, le plus difficile : la parcourir et commencer à corriger tous ces points de terminaison vulnérables. L’étape suivante consiste à exécuter cette procédure chaque jour pour vérifier qu’aucun nouveau point de terminaison dépourvu de l’en-tête x-frame-option n’est apparu. Un autre défi consiste à s’assurer que toutes les URL trouvées correspondent bien à des sites Web : les API n’ont pas besoin d’être protégées contre le clickjacking.

En conclusion

Cet incident montre à quel point il est important de disposer d’un programme de bug bounty, qui permet aux chercheurs de signaler les problèmes de sécurité de vos systèmes. Mais il est encore plus important de savoir comment traiter ces signalements : corriger le problème ne suffit pas. Sans ajouter un test qui reproduit le problème, vous ne pouvez pas vous assurer qu’il ne se reproduira pas. Nous sommes tous humains et nous faisons tous des erreurs. Veillons à utiliser du code qui nous aide à ne pas commettre les mêmes erreurs !