Owasp Pentest : présentation de l’OTG ou WSTG

Dans cet article, nous allons revenir sur deux notions clés de la cybersécurité : l’OWASP et le SDLC (Software Development Life Cycle). La première concerne la sécurité des applications web et la deuxième la sécurité dans le processus de développement des logiciels.

OTG ou WSTG : un socle commun pour le pentest

Au cours de notre activité de pentesteur, nous sommes amenés à évaluer la sécurité de nombreuses applications web avec des composants qui diffèrent entre chacune de ces applications. Chaque pentesteur possède sa propre méthodologie pour réaliser ces tests d'intrusion. Cependant, ils sont régis par un socle commun qui a été mis en place par l’OWASP avec le WSTG (Web Security Testing Guide) ou plus généralement appelé OTG (OWASP Testing Guide).

Qu’est-ce que l’OWASP ?

L’Open Web Application Security Project (OWASP) est une communauté internationale dont l’objectif principale est d’améliorer la sécurité des logiciels applicatifs. Afin d’apporter ces améliorations, elles contribuent à différents niveaux au sein de la communauté en sécurité informatique. Notamment au travers de présentation et de publication d'outils comme ZAP Proxy qui permet de faciliter les tests d’intrusion web.

Cette organisation est également reconnue pour la publication de l’OWASP Top 10¹ qui regroupe les vulnérabilités les plus critiques rencontrées lors des différents tests de sécurité. En plus de tout cela, des plateformes de tests sont proposées afin de comprendre comment fonctionnent ces vulnérabilités et comment y remédier. L’exemple le plus connu est l’application web OWASP Juice Shop qui concentre l’entièreté des vulnérabilités recensées dans le top 10 mentionné ci-dessous.

Toutes ces initiatives permettent de promouvoir la sécurité au sein des applications web via différents vecteurs. Cela permet de toucher un public plus large pour renforcer la sécurité que ce soit au niveau des développeurs web, des étudiants ou même des pentesteurs pour découvrir de nouvelles attaques ou méthodes de tests.

L'OWASP est devenue une référence majeure dans le domaine de la sécurité des applications web et joue un rôle essentiel dans la diffusion des connaissances et l'amélioration de la sécurité des logiciels dans le monde entier.

Le Testing Project de l'OWASP

Le "Testing Project" de l'OWASP est l'un des nombreux projets open source développés par l'OWASP pour promouvoir la sécurité des applications web. Le but principal de ce projet est de fournir des ressources et des outils permettant d'évaluer la sécurité des applications web, de détecter les vulnérabilités et de tester leur résistance aux attaques.

Notons que le projet fournit un cadre de test complet, et pas seulement une checklist. Ainsi, les lecteurs peuvent s’appuyer sur le cadre qu’il fournit comme modèle pour construire leurs propres programmes de test ou pour qualifier les processus d’autres personnes. Le Guide des Tests décrit en détail à la fois le cadre général des tests et les techniques requises pour les mettre en œuvre dans la pratique.

Le guide donne une vue d'ensemble des éléments nécessaires à la réalisation d'un programme complet de sécurité des applications Web. Il peut être utilisé comme référence et comme méthodologie pour déterminer l'écart entre les pratiques existantes et les meilleures pratiques du secteur.

Autrefois, dédié aux tests d'applications Web, le guide de l’OWASP a évolué et a été élargi aux tests intégrés dans le cycle de vie du développement logiciel. Ce qui nous permet de faire la transition avec la notion suivante : le SDLC.

SDLC (Software Development Life Cycle)

Aujourd'hui, la plupart des professionnels ne testent la sécurité de leurs logiciels ou de leurs applications web qu'une fois développés et en phase de déploiement. Il s'agit généralement d'une pratique très inefficace et peu rentable sur le long terme.

L'une des meilleures méthodes pour empêcher l'apparition de défauts de sécurité dans les applications de production consiste à améliorer le cycle de vie du développement logiciel (SDLC) en incluant la sécurité dans chacune de ses phases. Un SDLC est une structure imposée au développement d'artefacts logiciels.

« Patch-and-penetrate» : une approche révolue

Les professionnels de la cybersécurité ont pris conscience des limites du modèle « patch-and-penetrate », omniprésent dans le secteur au cours des années 1990. Ledit modèle consiste à corriger un défaut de sécurité signalé, mais sans enquêter correctement sur sa cause profonde. Ce modèle est généralement associé à la fenêtre de vulnérabilité, également appelée fenêtre d'exposition. L'évolution des vulnérabilités dans les logiciels courants utilisés dans le monde entier a montré l'inefficacité de ce modèle.

Des études sur les vulnérabilités, telles que l'Internet Security Threat Report de Symantec, ont montré qu'avec le temps de réaction des attaquants dans le monde entier, la fenêtre de vulnérabilité typique ne laisse pas suffisamment de temps pour l'installation de correctifs, puisque le délai entre la découverte d'une vulnérabilité et le développement et la diffusion d'une attaque automatisée contre celle-ci diminue chaque année.

De plus, le modèle « patch-and-penetrate » se base sur plusieurs hypothèses incorrectes. De nombreux utilisateurs pensent que les correctifs interfèrent avec les opérations normales ou risquent d’impacter les applications existantes. Il est également faux de supposer que tous les utilisateurs sont au courant des correctifs récemment publiés. Par conséquent, tous les utilisateurs d'un produit n'appliqueront pas les correctifs, soit parce qu'ils pensent que les correctifs peuvent interférer avec le fonctionnement du logiciel, soit parce qu'ils n'ont pas connaissance de l'existence du correctif.

D’où l’importance d'intégrer la sécurité dans le cycle de vie du développement logiciel (SDLC) pour éviter les problèmes récurrents dans une application. Les développeurs peuvent intégrer la sécurité dans le SDLC en élaborant des normes, des politiques et des directives qui s'intègrent dans la méthodologie de développement. La modélisation des menaces et d'autres techniques devraient être utilisées pour aider à affecter les ressources appropriées aux parties d'un système qui sont les plus à risque.

Il faut penser stratégique et pas tactique.

Mise en œuvre de DevSecOps dans le SDLC

DevSecOps est une approche stratégique qui réunit le développement, la sécurité, les opérations et l’infrastructure en tant que code (IaaS) dans un cycle de livraison continu et automatisé. Son objectif : surveiller, automatiser et mettre en œuvre la sécurité à toutes les étapes du cycle de vie des logiciels, y compris les phases de planification, de développement, de construction, de test, de déploiement, d’exploitation et de surveillance.

Il faut savoir qu’en mettant en œuvre la sécurité à toutes les étapes du processus de développement des logiciels, vous réduisez le risque de problèmes de sécurité en production, minimisez le coût de la conformité et livrez les logiciels plus rapidement. Dès lors, la question qui se pose est comment intégrer le DevSecOps dans le SDLC ?

Pour cela, il convient de respecter 5 étapes clés :

1. Développement local sécurisé : commencez par établir des environnements de travail sécurisés. Lorsque vous créez une application, vous écrivez du code source et intégrez des composants ensemble.

2. Contrôle des versions et analyse de la sécurité : lorsque plusieurs personnes sont impliquées dans une séquence de code, il est plus difficile d'identifier les vulnérabilités et d'y remédier. Les systèmes de versionning comme git peuvent être utiles à cet égard. Si un membre de l'équipe télécharge une séquence de code, il est fortement recommandé d'effectuer des tests de sécurité automatisés sur le noyau et les dépendances du code.

3. Intégration et déploiement continus (CI/CD) : lors de la compilation du paquet/de l'image de l’application, vous devez vous assurer que votre système ou votre outil de pipeline (Jenkins, GitLab, …) dispose d'une sécurité appropriée. Il doit utiliser le protocole HTTPS, être sécurisé et correctement renforcé.

4. Déploiement : lorsque vous déployez votre application dans un environnement, insérez des variables d'environnement et des informations d'identification via votre outil CI/CD.

5. Sécurité de l'infrastructure : lors du déploiement de votre application, veillez à mettre en place un pare-feu et un système de détection d'intrusion (IDS) sur tous les hôtes des conteneurs.

Testez tôt et testez souvent

Lorsqu'un bug est détecté tôt dans le SDLC, il peut être corrigé plus rapidement et à moindre coût. À cet égard, un bug de sécurité n'est pas différent d'un bug fonctionnel ou de performance. Pour y parvenir, il est essentiel de former les équipes de développement et d'assurance qualité aux problèmes de sécurité courants et aux moyens de les détecter et de les prévenir. Bien que de nouvelles bibliothèques, de nouveaux outils ou de nouveaux langages puissent aider à concevoir des programmes présentant moins de bogues de sécurité, de nouvelles menaces apparaissent constamment et les développeurs doivent être conscients de celles qui affectent les logiciels qu'ils développent. La formation aux tests de sécurité aide également les développeurs à acquérir l'état d'esprit requis pour tester une application du point de vue d'un attaquant.

Automatisation des tests

Dans les méthodologies de développement modernes telles qu’agile, devops/devsecops, ou le développement rapide d'applications (RAD), il faut envisager d'intégrer les tests de sécurité dans les flux de travail d'intégration continue/déploiement continu (CI/CD) afin de maintenir les informations/analyses de sécurité de base. Pour ce faire, il est possible de tirer parti des tests dynamiques de sécurité des applications (DAST), des tests statiques de sécurité des applications (SAST), de l'analyse de la composition logicielle (SCA) ou des outils de suivi des dépendances au cours des flux de production automatisés standard ou à intervalles réguliers.

Le SDLC donne un cadre essentiel pour la création méthodique, efficace et sécurisée de logiciels.