web methodology
1.0.0
Sautez directement à la méthodologie, hébergée dans ce Wiki de ce repo.
Alternativement, consultez le modèle Google Sheets pour le suivi des tests.
Cette méthodologie présente un guide d'opinion sur la façon de mener une évaluation de la sécurité des applications Web. L'accent principal est de dénommer clairement tous les principaux domaines qu'un testeur doit couvrir lors d'un examen de la sécurité. En tant qu'outil, les testeurs de sécurité peuvent apprendre du document et l'utiliser pour façonner leur processus de test. Il peut également être utilisé par les développeurs pour comprendre quels types de vulnérabilités peuvent exister dans leurs applications et les meilleures pratiques qu'ils devraient mettre en œuvre pour réduire le risque d'attaques.
Si vous êtes un débutant, cette méthodologie peut être considérée comme un document de référence plutôt qu'un tutoriel ou une introduction. Je recommande plutôt la WEB Sécurité de PortSwigger et la série de blogs d'Eric Rescorla comprenant le modèle de sécurité Web .
L'objectif de cette méthodologie est d'être aussi efficace que possible pour communiquer les problèmes à tester, pourquoi ce problème est important et (si possible) des recommandations sur la façon de tester et de résoudre efficacement le problème. Les principes directeurs que je suis lors de la rédaction du document sont:
Flexibilité, fiabilité, convivialité : le document doit être mis à jour et utilisable sur un large éventail d'applications différentes. Si la méthodologie se concentre trop sur des technologies ou des cadres spécifiques, les lecteurs ne seront pas sûrs si un problème donné s'applique à leur situation. Il devrait être utilisable par des lecteurs moins expérimentés (pour fournir une introduction à ce à quoi ressemblent les tests de sécurité moderne) et des lecteurs très expérimentés (pour les tenir à jour et aider à s'assurer qu'ils obtiennent une couverture complète).
Soyez succinct : le document doit être aussi succinct que possible pour expliquer chaque catégorie ou problème. Aller directement au cœur de la question et fournir des références de haute qualité en cas de besoin pour plus d'informations. Évitez de faire gonfler le document avec des informations sur un seul problème, lorsqu'un problème n'est qu'une petite partie de l'ensemble du document.
Soyez opiniâtre : n'hésitez pas à énoncer clairement les meilleures pratiques. Plus important encore, n'essayez pas de couvrir tous les problèmes de sécurité possibles - en particulier lorsqu'un problème a un impact minimal ou aucun dans la plupart des situations. Si un problème propose une gamme de recommandations acceptables, faites une suggestion sécurisée et largement applicable et comptez sur le lecteur pour ajuster la recommandation de leur contexte spécifique.
En fin de compte, aucune méthodologie ne remplace le jugement d'un testeur expérimenté qui peut prendre en compte le contexte de leur application spécifique. Un serveur HTTP intégré à domicile, écrit en C, aura des vulnérabilités très différentes de celle d'un microservice Kubernetes en utilisant le dernier framework Web avec un frontend React. Ce document définit une base de référence qui peut être utilisée par toute personne intéressée à améliorer la sécurité des applications Web et sert de norme à laquelle les testeurs peuvent se tenir afin de fournir des résultats de haute qualité.
