Les vulnérabilités que nous allons voir dans ce chapitre ne requièrent aucune compétence technique. Disons qu’elles font plutôt appel au bon état d’esprit (ou au mauvais, justement… celui que nous avons évoqué dans les premiers chapitres : penser comme un attaquant !).
Rapportez les fonctionnalités dangereuses
Lors d’un test d’intrusion, il pourra vous arriver de tomber sur des fonctionnalités qui sont à votre sens dangereuses.
C’est le fameux :
“Ce n’est pas un bug, c’est une fonctionnalité”.
Plaisanterie utilisée à l’origine pour se moquer des éditeurs de logiciels qui ne reconnaissent pas les erreurs dans leurs produits.
Rémi Gascou, notre pentester invité dans ce cours, nous partage une anecdote à ce sujet, pour nous raconter ce qu’il a fait lorsqu’il est tombé un jour sur une fonctionnalité dangereuse en auditant le système d’un client :
À L’instar de Rémi, il est de votre devoir, dans ces situations, de remonter au commanditaire ce qui relève de :
La partie métier (pour qui c’est probablement une fonctionnalité).
La partie sécurité (pour qui ce sera peut-être, comme pour vous, une vulnérabilité à corriger).
Reprenons maintenant notre application example.com .
Lorsqu'on a vérifié la fiabilité du contrôle d'accès et notamment le cloisonnement horizontal, on s'est aperçu que les médecins de n'importe quelle spécialité pouvaient accéder au dossier de n'importe quel patient, même si ça n'est pas le leur. Or, rappelez-vous, dans le premier rendez-vous avec Mikael Leroy, le CTO de example.com, on nous avait clairement dit que la protection des données des patients était primordiale. Cela veut dire que c'est quelque chose que nous devons absolument remonter. Et il faudra en discuter en restitution.
Repérez les fonctionnalités bancales
Voici un autre exemple, tiré d’une anecdote, qui rentre dans la catégorie des vulnérabilités “inclassables”. Je testais pour une banque une application web interne dont le seul et unique but était d’afficher des fichiers PDF confidentiels de manière sécurisée, pour éviter ou limiter au maximum le vol de ces documents.
Je commence mon test, j’ouvre le premier document… et là je trouve l’interface très familière : la même interface qu’on retrouve quand on ouvre un fichier PDF dans son navigateur, l’interface ci-dessous avec les boutons “Télécharger” et “Imprimer” en moins.
Je me dis : “Bizarre, ça normalement c’est du JavaScript. Comment font-ils pour garder les fichiers confidentiels ?”. Je vais voir du côté de mon proxy et mes doutes se confirment : le fichier est envoyé directement au client au format binaire, puis affiché en JavaScript.
Donc le fichier est littéralement envoyé au navigateur, dans son intégralité, au format PDF, ce qui permet de le récupérer sans effort en interceptant la requête, et de faire précisément ce que l’application était censée empêcher : récupérer les fichiers. Plus qu’à appeler le commanditaire pour lui dire que le pentest ne sert à rien, que l’application, by design, ne peut pas répondre au besoin. En discutant avec les développeurs, leur réponse était “On ne peut pas télécharger ou imprimer le fichier, on a enlevé les boutons. On a répondu au besoin.” Je résume, mais c’était la ligne de défense des développeurs, pour eux ils avaient respecté le cahier des charges.
Adel et Rémi ont eux aussi rencontré des fonctionnalités un peu bancales en auditant des applications.
Terminons par la vérification des informations réglementaires, notamment par rapport au recueil du consentement de l’utilisateur.
Vérifiez la conformité réglementaire de l'application web
Ce n’est pas là que nous allons trouver des vulnérabilités techniques qui permettent de compromettre l’application, mais c’est quelque chose que j’ai pris l’habitude de vérifier car cela peut représenter un risque qui va peser sur l’application.
Nous ne sommes pas juristes, et ce cours n’est pas un cours de droit du numérique. Je vais donc m’appuyer sur les textes réglementaires pour :
éviter toute interprétation ;
être le plus factuel possible ;
souligner ce qu’il est important de regarder et de relever, en tant que pentester.
Intéressons-nous donc à ce qu’un pentester peut apporter, techniquement, sur la vérification des principales obligations légales (pas à ce que doit contenir tel ou tel type d’application).
Pour effectuer ces vérifications par rapport aux cookies, vous pouvez, au choix :
regarder quand et comment sont positionnés les cookies au travers de l’historique de Burp ;
utiliser un outil comme un add-on de navigateur tel que Cookie Quick Manager dans Firefox ;
aller voir dans les outils de développement de votre navigateur. Exemple :
Les vulnérabilités de directory listing ne sont en soi pas dangereuses et je n’expliquerai pas cette faiblesse dans ce cours, car c’est une erreur de configuration plus qu’une vulnérabilité technique. Mais si elles permettent d’accéder à des données sensibles, le client va vouloir savoir que ses données sont publiques !
Avant de conclure, il me semblait important de partager des histoires de “ratés” pendant des tests d’intrusion ; parce que cela arrive, et même aux meilleurs :
En résumé
Toutes les vulnérabilités ne nécessitent pas de faire preuve de beaucoup d’imagination ou de chaîner trois techniques nouvelles en bypassant deux contre-mesures de sécurité. La réalité est bien souvent plus simple, et des fonctionnalités légitimes pour le métier sont parfois des vulnérabilités, du point de vue de la cybersécurité.
Il faut comprendre le métier des applications que vous testez pour imaginer ce qui est important pour l’application. Il faut également prendre du recul par rapport à vos constats ou vos tests, pour identifier les scénarios de risques impactants.
Prendre quelques minutes pour vérifier que les dispositions légales standard sont bien respectées est une bonne pratique (notamment, au niveau du recueil du consentement et des cookies). Le commanditaire vous remerciera de lui avoir évité une hypothétique mise en demeure de la CNIL !
Nous en avons terminé avec les constats. Il est temps de passer à la partie que les auditeurs aiment généralement moins, mais qui est tout autant nécessaire que les tests : la formalisation et la restitution. Allons-y !
