Le projet de test OWASP

Introduction

Le projet OWASP Testing est en développement depuis de nombreuses années. L'objectif du projet est d'aider les gens à comprendre le quoi, le pourquoi, le quand, le où et le comment des tests d'applications web. Le projet a fourni un cadre de test complet, et non pas simplement une simple liste de contrôle ou une prescription des problèmes qui devraient être résolus. Les lecteurs peuvent utiliser ce cadre comme modèle pour construire leurs propres programmes de test ou pour qualifier les processus d'autres personnes. Le guide de test décrit en détail à la fois le cadre général de test et les techniques requises pour mettre en oeuvre le cadre dans la pratique.

L'écriture du guide de test s'est avérée être une tâche difficile. Il a été difficile d'obtenir un consensus et de développer un contenu qui permette aux gens d'appliquer les concepts décrits dans le guide, tout en leur permettant de travailler dans leur propre environnement et culture. Il a également été difficile de modifier l'orientation des tests d'applications web, passant des tests de pénétration à des tests intégrés au cycle de vie du développement logiciel.

Cependant, le groupe est très satisfait des résultats du projet. De nombreux experts de l'industrie et professionnels de la sécurité, dont certains sont responsables de la sécurité des logiciels dans certaines des plus grandes entreprises du monde, valident le cadre de test. Ce cadre aide les organisations à tester leurs applications web afin de construire des logiciels fiables et sécurisés. Le cadre ne met pas simplement en évidence les points faibles, bien que ce soit certainement un sous-produit de nombreux guides et listes de contrôle OWASP. En tant que telles, des décisions difficiles ont dû être prises quant à la pertinence de certaines techniques et technologies de test. Le groupe comprend parfaitement que tout le monde ne sera pas d'accord avec toutes ces décisions. Cependant, OWASP est capable de prendre de la hauteur et de changer la culture au fil du temps grâce à la sensibilisation et à l'éducation, basées sur le consensus et l'expérience.

Le reste de ce guide est organisé comme suit : cette introduction couvre les prérequis des tests d'applications web et la portée des tests. Elle couvre également les principes des tests réussis et les techniques de test, les meilleures pratiques pour les rapports et les analyses de rentabilité pour les tests de sécurité. Le chapitre 3 présente le cadre de test OWASP et explique ses techniques et ses tâches en relation avec les différentes phases du cycle de vie du développement logiciel. Le chapitre 4 explique comment tester des vulnérabilités spécifiques (par exemple, l'injection SQL) par l'inspection du code et les tests de pénétration.

Mesurer la sécurité : l'économie des logiciels non sécurisés

Un principe de base de l'ingénierie logicielle est résumé dans une citation de Controlling Software Projects: Management, Measurement, and Estimates par Tom DeMarco :

Vous ne pouvez pas contrôler ce que vous ne pouvez pas mesurer.

Les tests de sécurité ne sont pas différents. Malheureusement, mesurer la sécurité est un processus notoirement difficile.

Un aspect qui doit être souligné est que les mesures de sécurité concernent à la fois les problèmes techniques spécifiques (par exemple, la prévalence d'une certaine vulnérabilité) et la façon dont ces problèmes affectent l'économie des logiciels. La plupart des techniciens comprendront au moins les problèmes de base, ou ils peuvent avoir une compréhension plus approfondie des vulnérabilités. Malheureusement, peu sont capables de traduire ces connaissances techniques en termes monétaires et de quantifier le coût potentiel des vulnérabilités pour l'entreprise du propriétaire de l'application. Tant que cela ne se produira pas, les DSI ne seront pas en mesure d'élaborer un retour sur investissement de sécurité précis et, par conséquent, d'affecter des budgets appropriés pour la sécurité des logiciels.

Bien que l'estimation du coût des logiciels non sécurisés puisse sembler une tâche ardue, il y a eu beaucoup de travail dans ce sens. En 2020, le Consortium for IT Software Quality a résumé :

... le coût des logiciels de mauvaise qualité aux Etats-Unis en 2018 est d'environ 2,84 billions de dollars...

Le cadre décrit dans ce document encourage les gens à mesurer la sécurité tout au long du processus de développement. Ils peuvent ensuite relier le coût des logiciels non sécurisés à l'impact qu'il a sur l'entreprise, et par conséquent développer des processus métier appropriés, et affecter des ressources pour gérer le risque. N'oubliez pas que la mesure et les tests des applications web sont encore plus critiques que pour les autres logiciels, car les applications web sont exposées à des millions d'utilisateurs via Internet.

Qu'est-ce que le test ?

De nombreuses choses doivent être testées pendant le cycle de vie du développement d'une application web, mais que signifie réellement le terme « test » ? Le dictionnaire Oxford de l'anglais définit le « test » comme :

test (nom) : une procédure destinée à établir la qualité, la performance ou la fiabilité de quelque chose, en particulier avant qu'il ne soit largement utilisé.

Aux fins du présent document, le test est un processus de comparaison de l'état d'un système ou d'une application par rapport à un ensemble de critères. Dans le secteur de la sécurité, les gens testent fréquemment par rapport à un ensemble de critères mentaux qui ne sont ni bien définis ni complets. En conséquence, de nombreux étrangers considèrent les tests de sécurité comme un art noir. Le but de ce document est de changer cette perception et de permettre aux personnes sans connaissance approfondie de la sécurité de faire une différence dans les tests.

Pourquoi effectuer des tests ?

Ce document est conçu pour aider les organisations à comprendre ce qui constitue un programme de test et à identifier les étapes à entreprendre pour construire et exploiter un programme de test d'applications web moderne. Le guide donne une vue d'ensemble des éléments nécessaires pour mettre en place un programme complet de sécurité des applications web. Ce guide peut être utilisé comme référence et comme méthodologie pour aider à déterminer l'écart entre les pratiques existantes et les meilleures pratiques de l'industrie. Ce guide permet aux organisations de se comparer à leurs pairs, de comprendre l'ampleur des ressources nécessaires pour tester et maintenir les logiciels, ou de se préparer à un audit. Ce chapitre n'entre pas dans les détails techniques de la façon de tester une application, car l'intention est de fournir un cadre organisationnel de sécurité typique. Les détails techniques sur la façon de tester une application, dans le cadre d'un test de pénétration ou d'une revue de code, seront couverts dans les parties restantes de ce document.

Quand tester ?

La plupart des gens aujourd'hui ne testent pas les logiciels tant qu'ils n'ont pas déjà été créés et qu'ils ne sont pas en phase de déploiement de leur cycle de vie (c'est-à-dire que le code a été créé et instancié dans une application web fonctionnelle). C'est généralement une pratique très inefficace et prohibitive en termes de coûts. L'une des meilleures méthodes pour empêcher les bogues de sécurité d'apparaître dans les applications de production est d'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. Si un SDLC n'est pas actuellement utilisé dans votre environnement, il est temps d'en choisir un ! La figure suivante montre un modèle SDLC générique ainsi que le coût (estimé) croissant de la correction des bogues de sécurité dans un tel modèle.

Figure 2-1 : Modèle SDLC générique

Les entreprises doivent inspecter leur SDLC global pour s'assurer que la sécurité fait partie intégrante du processus de développement. Les SDLC doivent inclure des tests de sécurité pour s'assurer que la sécurité est adéquatement couverte et que les contrôles sont efficaces tout au long du processus de développement.

Que tester ?

Il peut être utile de considérer le développement logiciel comme une combinaison de personnes, de processus et de technologie. Si ce sont les facteurs qui « créent » le logiciel, alors il est logique que ce soient les facteurs qui doivent être testés. Aujourd'hui, la plupart des gens testent généralement la technologie ou le logiciel lui-même.

Un programme de test efficace doit comporter des composants qui testent les éléments suivants :

• Personnes – pour s'assurer qu'il y a une éducation et une sensibilisation adéquates ;
• Processus – pour s'assurer qu'il existe des politiques et des normes adéquates et que les gens savent comment suivre ces politiques ;
• Technologie – pour s'assurer que le processus a été efficace dans sa mise en oeuvre.

A moins d'adopter une approche holistique, le simple fait de tester la mise en oeuvre technique d'une application ne permettra pas de découvrir les vulnérabilités de gestion ou opérationnelles qui pourraient être présentes. En testant les personnes, les politiques et les processus, une organisation peut détecter les problèmes qui se manifesteraient plus tard par des défauts dans la technologie, éradiquant ainsi les bogues très tôt et identifiant les causes profondes des défauts. De même, le fait de ne tester que certains des problèmes techniques qui peuvent être présents dans un système se traduira par une évaluation incomplète et inexacte de la posture de sécurité.

Denis Verdon, responsable de la sécurité de l'information chez Fidelity National Financial, a présenté une excellente analogie pour cette idée fausse lors de la conférence OWASP AppSec 2004 à New York :

Si les voitures étaient construites comme des applications... les tests de sécurité n'assumeraient qu'un impact frontal. Les voitures ne seraient pas testées au roulis, ni testées pour la stabilité lors de manoeuvres d'urgence, l'efficacité des freins, l'impact latéral et la résistance au vol.

Comment référencer les scénarios WSTG

Chaque scénario a un identifiant au format WSTG--, où : 'category' est une chaîne de 4 caractères en majuscules qui identifie le type de test ou de faiblesse, et 'number' est une valeur numérique complétée par des zéros de 01 à 99. Par exemple : WSTG-INFO-02 est le deuxième test de collecte d'informations.

Les identifiants peuvent changer entre les versions, il est donc préférable que d'autres documents, rapports ou outils utilisent le format : WSTG---, où : 'version' est la balise de version sans ponctuation. Par exemple : WSTG-v42-INFO-02 serait compris comme signifiant spécifiquement le deuxième test de collecte d'informations de la version 4.2.

Si les identifiants sont utilisés sans inclure l'élément , ils doivent être considérés comme faisant référence au dernier contenu du guide de test de sécurité Web. Evidemment, au fur et à mesure que le guide grandit et change, cela devient problématique, c'est pourquoi les rédacteurs ou les développeurs doivent inclure l'élément de version.

Liaison

La liaison vers les scénarios du guide de test de sécurité Web doit se faire en utilisant des liens versionnés et non stable ou latest qui changeront certainement avec le temps. Cependant, l'intention de l'équipe de projet est que les liens versionnés ne changent pas. Par exemple : https://owasp.org/www-project-web-security-testing-guide/v42/4-Web_Application_Security_Testing/01-Information_Gathering/02-Fingerprint_Web_Server. Remarque : l'élément v42 fait référence à la version 4.2.

Commentaires et remarques

Comme pour tous les projets OWASP, nous accueillons volontiers les commentaires et les remarques. Nous aimons particulièrement savoir que notre travail est utilisé et qu'il est efficace et précis.