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

Compétences que vous maîtriserez

🔧 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 fois

Sauvegardez ceci : Cochez chaque case pour chaque fonctionnalité. La cohérence trouve des bugs que les tests aléatoires manquent.

Pourquoi la méthodologie fonctionne

Deux approches de test

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"

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'app

Suivre 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 proxy

Questions fréquemment posées

🎯 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