Donner accès au code source lors d’un pentest présente principalement des avantages ou des inconvénients, selon les points de vue !
Voici notre retour d’expérience, qui concerne en particulier les pentests d’applications web.
En quoi consiste l’analyse de code source lors d’un pentest ?
Avant d’entrer dans le vif du sujet, précisons ce que nous entendons par donner accès au code source, dans le contexte d’un pentest.
Un pentest correspond à un audit de sécurité avec l’angle d’approche d’un attaquant. De fait, la plupart des attaquants n’ont à priori pas accès au code source de l’application web qui sera auditée.
Si on donne accès au code source, peut-on alors parler de pentest ?
Il s’agit en fait d’une approche un peu hybride permettant de pousser plus loin certains aspects. En effet, donner accès au code source lors d’un pentest signifie qu’il s’agira bien de réaliser des tests du point de vue d’un attaquant (tests d’intrusion en boite noire ou en boite grise). Néanmoins, les pentesters auront la possibilité de consulter le code source s’ils jugent que cela leur est utile pour faciliter ou approfondir leurs recherches.
Dans ce cas de figure, il ne sera pas question de réaliser une analyse complète du code source, car ce n’est pas l’objectif d’un pentest mais d’un audit de code source. En effet, un audit de code source consiste à analyser le code en profondeur pour identifier des vulnérabilités ou des axes d’amélioration de sécurité.
Quels inconvénients à donner accès au code source lors d’un pentest ?
Ne pas biaiser l’approche attaquant
C’est la première des raisons, qui concerne typiquement les entreprises souhaitant évaluer ou prouver un niveau de risque en cas de cyberattaque.
Si l’objectif du pentest est d’évaluer le risque en cas d’attaque externe, des tests en boite noire (sans aucune information fournie aux pentesters) conviennent parfaitement. Pour évaluer le risque face à un utilisateur mal intentionné, des tests en boite grise (avec un accès utilisateur) permettront d’obtenir un feedback réaliste. Typiquement, un éditeur de solution SaaS aura besoin de connaitre les risques d’attaque externe ainsi que les risques pour ses autres clients dans le cas où l’un de ses comptes clients serait compromis. Un pentest en boite noire et boite grise convient parfaitement pour cela.
Si le code source est fourni aux pentesters, ceux-ci auront accès à des éléments non visibles pour la plupart des attaquants, ce qui revient à donner un niveau d’information maximal au-delà du périmètre exposé aux attaques. Le feedback sécurité sera potentiellement très intéressant, mais risque d’aller plus loin que ce qui est considéré comme prioritaire vu que cela dépassera le périmètre exposé publiquement. Dans certains cas, il y a un risque que les développeurs minimisent le feedback sécurité en se disant « oui mais c’est trop facile car ils avaient le code ». C’est pourquoi il est nécessaire de bien cadrer les objectifs du pentest ainsi que les attentes de l’équipe technique du client.
A noter tout de même que, dans la pratique, le fait que les pentesters aient accès au code source ne les empêchera pas de conduire aussi des attaques externes réalistes, et de faire un feedback sur les risques par ordre de priorité.
Confidentialité et confiance
La confiance est un aspect central quand il s’agit de trouver un prestataire de pentest, et plus encore s’il doit y avoir partage du code source. En effet, le code source est la propriété intellectuelle de l’entreprise, et une partie significative de la valeur d’un éditeur de logiciel ou d’une startup.
Le contrat de pentest inclura des clauses de confidentialité permettant de protéger le client. Celui-ci aura également intérêt à questionner le sérieux du prestataire, le profil de l’entreprise et celui des auditeurs en sécurité.
Transfert sécurisé
En plus de la confiance à proprement parler, et du respect de la confidentialité des informations échangées, se pose la question du transfert du code source de façon sécurisée.
Cette question est habituellement résolue de la façon suivante :
- Si le code source du client est sur Github (ou un équivalent), un accès externe temporaire sera ouvert pour les pentesters
- Autrement, le client pourra fournir une archive chiffrée contenant une copie de tous les fichiers du code source, via une plateforme d’échange de fichiers sécurisée
Facteurs psychologiques
Enfin, certaines réticences peuvent être d’ordre plus psychologique. On entend parfois de la part des clients : « on sait déjà que par endroits notre code n’est pas très propre, donc on préfère ranger notre chambre avant de laisser d’autres personnes y entrer ». En effet, pour les développeurs, il peut y avoir un ressenti inconfortable à devoir tout montrer, ce qui peut contribuer au fait de vouloir se focaliser sur les risques externes, au moins dans un premier temps. Cependant, l’objectif du test d’intrusion n’est pas de juger de la qualité du code de façon globale, mais de se focaliser sur les aspects qui impactent la sécurité.
Quels sont les avantages à donner accès au code source lors d’un pentest ?
Mapping et découverte du scope
Lors d’un test d’intrusion, la phase de mapping permet d’identifier l’étendue de la surface d’attaque. Concrètement, cela passe par beaucoup d’énumérations, afin d’identifier les chemins de l’application, ce qui consomme du temps et des ressources. Cette phase étant nécessaire, mais sans que cela représente beaucoup de valeur ajoutée, le fait d’avoir accès au code source permet de gagner du temps sur le mapping et de consacrer plus de temps à la recherche de vulnérabilités.
A noter que cette phase peut avoir un impact sur le scope du pentest, en cas de découverte de nouvelles portions exposées. Selon le projet, le scope pourra être étendu en conséquence, ou bien les nouvelles portions exposées seront signalées dans le rapport d’audit sans pour autant être inclues dans les tests d’intrusion.
Découverte et exploitation de vulnérabilités
Avoir accès au code source permet aussi de faciliter le travail sur les phases de découverte et d’exploitation, pour redéployer une partie des efforts sur les recherches les plus complexes nécessitant un haut niveau d’expertise.
Par exemple, lire le code source permet de vérifier directement les mises à jour des différents composants de l’application (librairies et autres composants), pour identifier ce type de vulnérabilités. Lire le code source permet aussi de valider certaines hypothèses plus rapidement, notamment sur les tests de droits, qui habituellement sont chronophages.
Au niveau de l’exploitation, un exemple typique concerne les failles XSS : voir directement dans le code source quelles règles de contrôle ont été mises en place permet de contourner plus facilement les filtres XSS. Ce qui en fin de compte permet une meilleure évaluation de l’impact des failles XSS en cas d’exploitation réussie par un attaquant externe.
Exhaustivité des tests
Dans un pentest peut se poser la question de l’exhaustivité, si cela est un objectif qui a été préalablement défini avec le client.
Certains types de failles peuvent être massivement présentes dans une application : on voit régulièrement ce cas pour les failles XSS. L’accès au code source permet alors aux pentesters de comprendre l’origine du problème et de montrer où les failles sont systématiquement présentes, sans risquer d’oublier certaines urls.
Conseils pour corriger
Cet aspect est en lien avec les remarques sur l’exhaustivité. Identifier les erreurs dans le code source permet d’identifier tous les endroits où certains types de failles sont présentes. Et donc de fournir des recommandations adaptées pour corriger les failles de l’application web.
De manière générale, en ayant accès au code source, les pentesters peuvent faire des recommandations plus pertinentes, car il y a moins de suppositions ou d’hypothèses sur la façon dont le code est construit.
Orienter et prioriser certains tests
Par ailleurs, consulter le code source, sans pour autant l’analyser de manière complète, peut permettre d’orienter les recherches pendant un pentest.
Notamment dans le cas d’un pentest non exhaustif, avec un temps limité pour rechercher les principales vulnérabilités présentes sur une application : consulter le code source permet à un pentester expérimenté d’avoir une appréhension de son niveau de qualité et de prioriser certains tests en conséquence.
Pour ou contre le fait de fournir le code source aux pentesters ?
Comme évoqué au tout début de cet article, cette question doit être tranchée en fonction des objectifs que l’équipe du client s’est fixés pour le pentest.
Certains CTO commanditaires d’un test d’intrusion auront une sensibilité en faveur d’une approche boite noire ou boite grise stricte, d’autres en faveur du partage de code source pour aller plus loin.
De notre point de vue, fournir le code source présente surtout des avantages, puisque cela permet d’optimiser le pentest sans pour autant empêcher de conduire des tests externes ou du point de vue d’un utilisateur standard. A noter que pour un même périmètre, donner accès au code source aura peu d’impact sur le budget de la prestation, puisque le temps gagné sur certaines tâches pourra être réinvesti sur d’autres recherches.
Ce que nous montre notre expérience, c’est qu’au fur et à mesure des tests d’intrusion récurrents, le niveau de sécurité d’une application web va en augmentant, puisque les développeurs répercutent les feedbacks des précédents audits de sécurité sur les nouveaux développements. Dans certains cas le résultat des pentests permet d’instaurer une véritable culture de sécurité en interne ainsi qu’une roadmap de sécurité pour l’équipe de développement.
C’est pourquoi nous recommandons, après plusieurs pentests en boite noire et boite grise sur le même scope, de fournir systématiquement le code source pour les prochains pentests afin de pousser plus loin l’analyse et permettre des recommandations de sécurité complémentaires à ce qui peut être détecté par un pentest classique.