Construire votre méthodologie
Une approche systématique pour trouver des vulnérabilités de manière cohérente
Ce que vous allez découvrir
🎯 Pourquoi c'est important
Les tests aléatoires trouvent des bugs aléatoires. Une méthodologie trouve des bugs de manière cohérente. Avoir une checklist garantit que vous ne manquez jamais les vulnérabilités courantes, tandis que la structure vous aide à travailler efficacement. Les meilleurs chasseurs ont tous leur propre méthodologie - maintenant vous allez construire la vôtre.
🔍 Ce que vous allez apprendre
- Créer une checklist de tests
- Tests basés sur les fonctionnalités vs basés sur les vulnérabilités
- Prioriser ce qu'il faut tester en premier
- Suivre les zones testées vs non testées
- Faire évoluer votre méthodologie au fil du temps
🚀 Votre première victoire
En 20 minutes, vous aurez une approche de test structurée qui rendra votre chasse plus efficace.
Compétences que vous maîtriserez
Tests systématiques
Ne manquez jamais une classe de vulnérabilité grâce à des checklists structurées
Priorisation
Concentrez votre temps sur les zones à fort impact en premier
Suivi de progression
Sachez ce que vous avez testé et ce qu'il reste
Amélioration continue
Faites évoluer votre méthodologie selon ce qui fonctionne
🔧 Votre checklist de tests (avec explications)
Utilisez ceci pour chaque fonctionnalité que vous testez. Chaque élément est expliqué pour que vous compreniez ce que vous recherchez :
# CHECKLIST DE TESTS FONDAMENTAUX
[ ] Authentication Bypass
# Pouvez-vous accéder aux pages protégées sans vous connecter ?
# Essayez de supprimer les tokens d'auth, manipuler les cookies
# Que se passe-t-il si vous visitez /admin directement ?
[ ] IDOR/BOLA (changer les IDs dans tous les paramètres)
# IDOR = Insecure Direct Object Reference
# BOLA = Broken Object Level Authorization (terme API)
# Les deux signifient la même chose : changer les IDs pour accéder
# aux données d'autres utilisateurs (commandes, profils, documents)
[ ] Authorization (accéder aux données d'autres utilisateurs)
# Différent de l'authentification - vous êtes connecté
# mais pouvez-vous faire des choses que vous ne devriez pas ?
# Utilisateur A accédant aux données privées de l'Utilisateur B
[ ] XSS (reflected, stored, DOM)
# Pouvez-vous injecter du JavaScript qui s'exécute ?
# Reflected : Dans les paramètres URL, apparaît dans la réponse
# Stored : Dans la base de données, affecte d'autres utilisateurs
# DOM : Le JS côté client gère votre entrée de manière non sécurisée
[ ] SQL Injection
# Requêtes de base de données construites avec votre entrée
# Test : ' OR 1=1-- , sleep(5), payloads basés sur les erreurs
# Signes : Erreurs de base de données, délais, comportement différent
[ ] CSRF (actions modifiant l'état)
# Cross-Site Request Forgery
# Pouvez-vous piéger un utilisateur connecté pour effectuer des actions ?
# Tokens CSRF manquants sur changement de mot de passe, email, etc.
[ ] Open Redirect
# Un paramètre URL contrôle où vont les utilisateurs
# /redirect?url=https://evil.com
# Utile pour le phishing, vol de tokens OAuth
[ ] Information Disclosure
# Données sensibles exposées : clés API, IPs internes
# Endpoints de debug, messages d'erreur verbeux, dossiers .git
# Vérifier /robots.txt, /sitemap.xml pour les chemins cachés
[ ] Rate Limiting (sur les fonctions sensibles)
# Pas de limite sur les tentatives de connexion = brute force possible
# Pas de limite sur la réinitialisation de mot de passe = énumération de comptes
# Pas de limite sur la vérification OTP = contournement 2FA
[ ] Business Logic Flaws
# Vulnérabilités spécifiques à l'application
# Acheter des quantités négatives, sauter des étapes dans le checkout
# Appliquer des codes de réduction plusieurs foisSauvegardez ceci : Cochez chaque case pour chaque fonctionnalité. La cohérence trouve des bugs que les tests aléatoires manquent.
Pourquoi la méthodologie fonctionne
Le problème avec les tests aléatoires
Sans structure, vous pourriez passer des heures sur une fonctionnalité tout en ignorant complètement une autre qui a des vulnérabilités critiques. Vous testez XSS sur la connexion mais oubliez de vérifier la page de profil. Vous trouvez un IDOR mais en manquez cinq autres parce que vous n'avez pas vérifié systématiquement tous les endpoints. Les tests aléatoires produisent des résultats aléatoires - parfois vous avez de la chance, souvent non.
La puissance des tests systématiques
Une méthodologie assure la couverture. Quand vous avez une checklist, vous savez que chaque fonctionnalité est testée pour chaque classe de vulnérabilité. Vous ne sauterez pas accidentellement l'endpoint de paiement parce que vous avez été distrait par quelque chose de brillant sur la page de profil. Un effort constant produit des résultats constants.
Deux approches de test
"Une bonne méthodologie est un document vivant - améliorez-la avec chaque cible."
Tests basés sur les fonctionnalités
Choisissez une fonctionnalité, testez chaque type de vulnérabilité dessus avant de passer à la suite. Cette approche vous aide à comprendre l'application en profondeur.
# TESTS BASÉS SUR LES FONCTIONNALITÉS
# Exemple : Fonctionnalité de profil utilisateur
ÉTAPE 1 : Cartographier tous les endpoints liés aux profils
GET /api/users/me # Votre propre profil
GET /api/users/{id} # Profil de n'importe quel utilisateur
PUT /api/users/me # Mettre à jour votre profil
POST /api/users/me/avatar # Uploader une photo de profil
GET /api/users/me/settings # Paramètres du compte
ÉTAPE 2 : Parcourir votre checklist sur cette fonctionnalité
[x] IDOR : Puis-je GET /api/users/AUTRE_ID_UTILISATEUR ?
[x] IDOR : Puis-je PUT vers /api/users/AUTRE_ID_UTILISATEUR ?
[x] XSS : Injecter des payloads dans les champs nom, bio, localisation
[x] Mass Assignment : Ajouter "role": "admin" à la requête PUT
[x] File Upload : Que se passe-t-il avec .php, .svg, fichiers énormes ?
[x] Info Disclosure : La réponse inclut-elle des champs sensibles ?
ÉTAPE 3 : Passer à la fonctionnalité suivante
Maintenant tester : paiements, messagerie, paramètres, etc.
POURQUOI ÇA MARCHE :
- Compréhension approfondie d'une zone avant de passer à la suite
- Trouve des bugs complexes qui couvrent plusieurs endpoints
- Construit un modèle mental du fonctionnement de la fonctionnalitéTests basés sur les vulnérabilités
Choisissez un type de vulnérabilité, testez chaque fonctionnalité pour celui-ci. Cette approche est efficace pour une couverture systématique.
# TESTS BASÉS SUR LES VULNÉRABILITÉS
# Exemple : Tester IDOR sur toute l'application
ÉTAPE 1 : Trouver tous les endpoints avec des IDs
/api/orders/{id}
/api/documents/{id}
/api/invoices/{id}
/api/users/{id}/data
/api/messages/{id}
/api/projects/{id}
ÉTAPE 2 : Tester IDOR sur chacun systématiquement
Prérequis :
- Créer 2 comptes (Compte A et Compte B)
- Créer des ressources dans les deux comptes
Tester chaque endpoint :
- Le Compte A peut-il accéder aux commandes du Compte B ?
- Le Compte A peut-il modifier les documents du Compte B ?
- Tester les méthodes GET, PUT, PATCH, DELETE
- Vérifier les IDs numériques et les UUIDs
ÉTAPE 3 : Passer au type de vulnérabilité suivant
Maintenant tester : XSS partout, puis CSRF partout, etc.
POURQUOI ÇA MARCHE :
- Efficace pour une classe de vulnérabilité spécifique
- Vous entrez en "mode chasse IDOR" - reconnaissance de patterns
- Facile à suivre : "J'ai testé tous les IDOR, je passe aux XSS"Quelle approche devriez-vous utiliser ?
La plupart des chasseurs combinent les deux. Utilisez l'approche basée sur les fonctionnalités lorsque vous apprenez une nouvelle cible pour comprendre son fonctionnement. Utilisez l'approche basée sur les vulnérabilités lorsque vous voulez assurer une couverture complète d'une classe de bugs. Il n'y a pas de réponse unique - développez ce qui fonctionne pour votre style.
Zones à fort impact à prioriser
Toutes les fonctionnalités ne sont pas égales. Ces zones ont la plus grande probabilité de vulnérabilités critiques et les plus gros paiements :
# ORDRE DE TEST PRIORISÉ (plus fort impact en premier)
1. Flux d'authentification/connexion
Pourquoi : Prise de contrôle de compte = Sévérité critique
Tester : Réinitialisation de mot de passe, OAuth, gestion de session
2. Fonctionnalité de réinitialisation de mot de passe
Pourquoi : Souvent a des fuites de tokens, énumération, contournement
Tester : Token dans l'URL, tokens faibles, pas de rate limiting
3. Fonctionnalités de paiement/financières
Pourquoi : Impact financier direct, toujours haute sévérité
Tester : Manipulation de prix, IDOR sur les transactions
4. Panneaux admin/paramètres
Pourquoi : Potentiel d'escalade de privilèges
Tester : Les utilisateurs normaux peuvent-ils accéder aux endpoints admin ?
5. Fonctions d'upload de fichiers
Pourquoi : Peut mener à RCE, stored XSS, path traversal
Tester : Contournement d'extension, manipulation de content-type
6. Endpoints API avec des IDs utilisateur
Pourquoi : Mine d'or IDOR - les développeurs oublient les vérifications d'auth
Tester : Chaque endpoint qui prend un paramètre ID
7. Fonctionnalités d'export/téléchargement
Pourquoi : Fuient souvent des données sensibles, potentiel SSRF
Tester : Quelles données sont incluses ? Pouvez-vous exporter les données d'autres ?
8. Systèmes d'invitation/partage
Pourquoi : Complexité du contrôle d'accès = bugs
Tester : Pouvez-vous escalader les permissions partagées ?
9. Intégrations OAuth
Pourquoi : Fuite de tokens, problèmes de liaison de comptes
Tester : Manipulation de redirect_uri, paramètre state
10. Fonctionnalités nouvellement sorties
Pourquoi : Moins testées, densité de bugs plus élevée
Où : Vérifier les changelogs, articles de blog, mises à jour d'appSuivre votre progression
De bonnes notes séparent les chasseurs efficaces de tous les autres. Quand vous revenez sur une cible des mois plus tard, vos notes vous disent exactement ce que vous avez fait et ce qu'il reste.
Modèle de notes
# Cible : company.com
# Date de début : 2024-01-15
# Dernière mise à jour : 2024-01-22
## Stack technique (découverte pendant la recon)
- Backend : Ruby on Rails (header X-Powered-By)
- Base de données : PostgreSQL (messages d'erreur)
- Frontend : React (patterns dans le code source)
- CDN : Cloudflare
## Fonctionnalités testées
- [x] Inscription utilisateur
- [x] Connexion/authentification
- [x] Réinitialisation de mot de passe
- [ ] Profils utilisateur
- [ ] Système de paiement
- [ ] Endpoints API v2 (nouvellement découverts)
## Découvertes intéressantes (pas encore signalées)
- La page de profil retourne l'email en JSON même pour d'autres utilisateurs
- Le token de réinitialisation de mot de passe apparaît dans l'URL (fuite potentielle via Referer)
- Endpoint de debug à /api/debug retourne des stack traces
- Rate limiting contourné avec le header X-Forwarded-For
## Bugs signalés
- #12345 : IDOR dans /api/orders/{id} (P2) - 500$ - Résolu
- #12346 : Stored XSS dans le champ bio (P3) - En attente de triage
## À investiguer
- [ ] Vérifier si les tokens de réinitialisation de mot de passe sont devinables
- [ ] Tester l'upload de fichier sur les photos de profil
- [ ] Énumérer les endpoints /api/v2/ (trouvés dans le JS)
- [ ] Vérifier le panneau admin à /internal/ (référencé dans un commentaire HTML)
## Notes
- L'entreprise utilise Stripe pour les paiements - scope limité ici
- L'app mobile utilise la même API - tester via proxyQuestions fréquemment posées
À quel point ma méthodologie doit-elle être détaillée ?
Commencez avec une checklist de 10 éléments que vous utilisez vraiment. Une checklist exécutée de manière cohérente bat une checklist de 200 éléments que vous ignorez. Ajoutez des éléments quand vous apprenez de nouvelles techniques qui trouvent des bugs. Supprimez les éléments qui ne produisent jamais de résultats pour vous. Votre méthodologie devrait évoluer en fonction de ce qui fonctionne.
Dois-je automatiser ou tester manuellement ?
Les deux, à des fins différentes. Automatisez la reconnaissance, l'énumération de sous-domaines et les vérifications de vulnérabilités simples (headers manquants, CVEs connus). Les tests manuels trouvent les failles de logique métier, les problèmes d'authentification complexes et les vulnérabilités chaînées que les scanners manquent. L'automatisation vous donne de l'étendue ; les tests manuels vous donnent de la profondeur. Les chasseurs les plus efficaces combinent les deux.
Quels outils dois-je utiliser pour suivre mes tests ?
Tout ce que vous utiliserez vraiment. Certains chasseurs utilisent Notion, Obsidian ou des applications de notes dédiées. D'autres utilisent des fichiers texte simples dans un repo git. Certains utilisent des tableurs. Le meilleur système est celui que vous maintiendrez. Commencez avec quelque chose de simple et faites-le évoluer à mesure que vous découvrez quelles informations vous devez suivre.
Comment savoir quand j'ai fini de tester une cible ?
Vous n'avez jamais vraiment "fini" - les applications changent constamment. Mais vous pouvez considérer une cible adéquatement testée quand : vous avez couvert toutes les fonctionnalités avec votre checklist, vous avez testé toutes les zones prioritaires, et vous trouvez des rendements décroissants (passer des heures sans nouvelles découvertes). À ce moment-là, passez à autre chose mais planifiez des revisites périodiques, surtout après que la cible annonce des mises à jour.
🎯 Vous avez une méthodologie !
Vous avez maintenant une approche structurée pour les tests : une checklist complète avec des explications, deux stratégies de test, des conseils de priorisation et un système de suivi. Une méthodologie cohérente produit des résultats cohérents.
Prêt à apprendre les vulnérabilités quick-win