Avant-propos par Eoin Keary

Introduction

Le problème des logiciels non sécurisés est peut-être le défi technique le plus important de notre époque. L'essor spectaculaire des applications web permettant le commerce, les réseaux sociaux, etc. n'a fait qu'accroître les exigences pour établir une approche robuste de l'écriture et de la sécurisation de notre Internet, de nos applications web et de nos données.

A l'Open Web Application Security Project® (OWASP®), nous essayons de faire du monde un endroit où les logiciels non sécurisés sont l'anomalie, et non la norme. Le guide de test OWASP a un rôle important à jouer dans la résolution de ce problème grave. Il est vital que notre approche des tests de logiciels pour les problèmes de sécurité soit basée sur les principes de l'ingénierie et de la science. Nous avons besoin d'une approche cohérente, reproductible et définie pour tester les applications web. Un monde sans normes minimales en termes d'ingénierie et de technologie est un monde en chaos.

Il va sans dire que vous ne pouvez pas construire une application sécurisée sans effectuer de tests de sécurité sur celle-ci. Les tests font partie d'une approche plus large pour construire un système sécurisé. De nombreuses organisations de développement de logiciels n'incluent pas les tests de sécurité dans leur processus standard de développement de logiciels. Ce qui est encore pire, c'est que de nombreux fournisseurs de sécurité proposent des tests avec des degrés de qualité et de rigueur variables.

Les tests de sécurité, en eux-mêmes, ne sont pas une mesure particulièrement bonne et autonome de la sécurité d'une application, car il existe un nombre infini de façons dont un attaquant pourrait faire échouer une application, et il n'est tout simplement pas possible de toutes les tester. Nous ne pouvons pas nous pirater nous-mêmes pour devenir sécurisés, car nous n'avons qu'un temps limité pour tester et défendre, alors qu'un attaquant n'a pas de telles contraintes.

En conjonction avec d'autres projets OWASP tels que le guide de revue de code, le guide de développement et des outils tels que ZAP, c'est un excellent début pour construire et maintenir des applications sécurisées. Ce guide de test vous montrera comment vérifier la sécurité de votre application en cours d'exécution. Je recommande fortement d'utiliser ces guides dans le cadre de vos initiatives de sécurité des applications.

Pourquoi OWASP ?

Créer un guide comme celui-ci est une entreprise énorme, nécessitant l'expertise de centaines de personnes à travers le monde. Il existe de nombreuses façons différentes de tester les failles de sécurité et ce guide capture le consensus des principaux experts sur la façon d'effectuer ces tests rapidement, précisément et efficacement. OWASP donne aux personnes partageant les mêmes idées en matière de sécurité la possibilité de travailler ensemble et de former une approche de pointe pour résoudre un problème de sécurité.

L'importance de rendre ce guide disponible de manière totalement gratuite et ouverte est essentielle pour la mission de la fondation. Il donne à chacun la possibilité de comprendre les techniques utilisées pour tester les problèmes de sécurité courants. La sécurité ne doit pas être un art noir ou un secret fermé que seuls quelques-uns peuvent pratiquer. Elle doit être ouverte à tous et non exclusive aux professionnels de la sécurité, mais aussi à l'assurance qualité, aux développeurs et aux responsables techniques. Le projet de construction de ce guide conserve cette expertise entre les mains des personnes qui en ont besoin - vous, moi et toute personne impliquée dans la construction de logiciels.

Ce guide doit parvenir entre les mains des développeurs et des testeurs de logiciels. Il n'y a pas assez d'experts en sécurité des applications dans le monde pour avoir un impact significatif sur le problème global. La responsabilité initiale de la sécurité des applications doit incomber aux développeurs car ce sont eux qui écrivent le code. Il ne devrait pas être surprenant que les développeurs ne produisent pas de code sécurisé s'ils ne le testent pas ou ne considèrent pas les types de bogues qui introduisent des vulnérabilités.

Maintenir ces informations à jour est un aspect essentiel de ce projet de guide. En adoptant l'approche wiki, la communauté OWASP peut faire évoluer et étendre les informations contenues dans ce guide pour suivre le rythme rapide de l'évolution du paysage des menaces de sécurité des applications.

Ce guide est un excellent témoignage de la passion et de l'énergie que nos membres et bénévoles du projet ont pour ce sujet. Il contribuera certainement à changer le monde, une ligne de code à la fois.

Adaptation et priorisation

Vous devriez adopter ce guide dans votre organisation. Vous devrez peut-être adapter les informations pour qu'elles correspondent aux technologies, aux processus et à la structure organisationnelle de votre organisation.

En général, il existe plusieurs rôles différents au sein des organisations qui peuvent utiliser ce guide :

• Les développeurs doivent utiliser ce guide pour s'assurer qu'ils produisent du code sécurisé. Ces tests doivent faire partie des procédures normales de code et de tests unitaires.
• Les testeurs de logiciels et l'assurance qualité doivent utiliser ce guide pour étendre l'ensemble des cas de test qu'ils appliquent aux applications. Détecter ces vulnérabilités tôt permet d'économiser beaucoup de temps et d'efforts plus tard.
• Les spécialistes de la sécurité doivent utiliser ce guide en combinaison avec d'autres techniques comme un moyen de vérifier qu'aucun trou de sécurité n'a été manqué dans une application.
• Les chefs de projet doivent tenir compte de la raison pour laquelle ce guide existe et du fait que les problèmes de sécurité se manifestent par des bogues dans le code et la conception.

La chose la plus importante à retenir lors de l'exécution des tests de sécurité est de continuellement reprioriser. Il existe une infinité de façons dont une application peut échouer, et les organisations ont toujours un temps et des ressources de test limités. Assurez-vous que le temps et les ressources sont utilisés à bon escient. Essayez de vous concentrer sur les failles de sécurité qui représentent un risque réel pour votre entreprise. Essayez de contextualiser le risque en termes d'application et de ses cas d'utilisation.

Ce guide est mieux considéré comme un ensemble de techniques que vous pouvez utiliser pour trouver différents types de failles de sécurité. Mais toutes les techniques ne sont pas d'égale importance. Essayez d'éviter d'utiliser le guide comme une liste de contrôle, de nouvelles vulnérabilités se manifestent toujours et aucun guide ne peut être une liste exhaustive de "choses à tester", mais plutôt un excellent point de départ.

Le rôle des outils automatisés

Il existe un certain nombre d'entreprises qui vendent des outils automatisés d'analyse et de test de sécurité. N'oubliez pas les limites de ces outils afin de pouvoir les utiliser pour ce pour quoi ils sont bons. Comme l'a dit Michael Howard lors de la conférence OWASP AppSec 2006 à Seattle, "Les outils ne rendent pas les logiciels sécurisés ! Ils aident à mettre à l'échelle le processus et à faire respecter les politiques."

Plus important encore, ces outils sont génériques - ce qui signifie qu'ils ne sont pas conçus pour votre code personnalisé, mais pour les applications en général. Cela signifie que, bien qu'ils puissent trouver certains problèmes génériques, ils n'ont pas une connaissance suffisante de votre application pour leur permettre de détecter la plupart des failles. D'après mon expérience, les problèmes de sécurité les plus graves sont ceux qui ne sont pas génériques, mais profondément imbriqués dans votre logique métier et la conception de votre application personnalisée.

Ces outils peuvent également être très utiles, car ils trouvent de nombreux problèmes potentiels. Bien que l'exécution des outils ne prenne pas beaucoup de temps, chacun des problèmes potentiels prend du temps à examiner et à vérifier. Si l'objectif est de trouver et d'éliminer les failles les plus graves le plus rapidement possible, demandez-vous si votre temps est mieux dépensé avec des outils automatisés ou avec les techniques décrites dans ce guide. Néanmoins, ces outils font certainement partie d'un programme de sécurité des applications bien équilibré. Utilisés à bon escient, ils peuvent soutenir vos processus globaux pour produire un code plus sécurisé.

Appel à l'action

Si vous construisez, concevez ou testez des logiciels, je vous encourage fortement à vous familiariser avec les conseils de test de sécurité contenus dans ce document. C'est une excellente feuille de route pour tester les problèmes les plus courants auxquels les applications sont confrontées aujourd'hui, mais elle n'est pas exhaustive. Si vous trouvez des erreurs, veuillez ajouter une note à la page de discussion ou effectuer vous-même la modification. Vous aiderez des milliers d'autres personnes qui utilisent ce guide.

Veuillez envisager de nous rejoindre en tant que membre individuel ou corporatif afin que nous puissions continuer à produire des documents comme ce guide de test et tous les autres grands projets d'OWASP.

Merci à tous les contributeurs passés et futurs de ce guide, votre travail contribuera à rendre les applications plus sûres dans le monde entier.

--Eoin Keary, membre du conseil d'administration d'OWASP, 19 avril 2013

Open Web Application Security Project et OWASP sont des marques déposées de l'OWASP Foundation, Inc.