🎯 Pourquoi c'est important

Certaines vulnérabilités sont partout si vous savez où chercher. Ces "quick wins" sont accessibles aux nouveaux chasseurs, rapportent de vraies récompenses et construisent votre réputation. Concentrez-vous ici d'abord avant de passer aux chaînes d'attaques complexes - vous apprendrez les applications tout en gagnant de l'argent.

🔍 Ce que vous allez apprendre

• IDOR/BOLA - accéder aux données d'autres utilisateurs (et pourquoi ça arrive)
• Open redirects - où ils comptent et comment démontrer l'impact
• Divulgation d'informations - ce qui rapporte vraiment des récompenses
• Subdomain takeover - revendiquer des ressources abandonnées
• Comment chaîner des bugs de faible sévérité en impact plus élevé

🚀 Votre première victoire

À la fin de ce chapitre, vous connaîtrez les vulnérabilités les plus susceptibles de vous rapporter votre première récompense - et comprendrez POURQUOI elles existent pour les trouver de manière cohérente.

"Votre première récompense n'a pas besoin d'être un P1. Commencez par ce qui est trouvable."

Qu'est-ce qu'IDOR et pourquoi ça existe ?

IDOR (Insecure Direct Object Reference) — aussi appelé BOLA (Broken Object Level Authorization) en sécurité API — survient quand une application expose des références à des objets internes (comme des IDs de base de données) et ne vérifie pas que l'utilisateur a la permission d'y accéder.

Pourquoi ça arrive : Les développeurs construisent des fonctionnalités comme "voir mon profil" ou "télécharger ma facture". Le code vérifie "l'utilisateur est-il connecté ?" mais oublie de vérifier "cet utilisateur POSSÈDE-t-il cette ressource ?" C'est une erreur facile :

# CODE VULNÉRABLE (exemple simplifié)
def get_invoice(request, invoice_id):
    # Vérification : L'utilisateur est-il connecté ? ✓
    if not request.user.is_authenticated:
        return "Veuillez vous connecter"

    # Vérification manquante : Cet utilisateur possède-t-il cette facture ? ✗
    invoice = Invoice.objects.get(id=invoice_id)
    return invoice.data  # Retourne N'IMPORTE QUELLE facture à N'IMPORTE QUEL utilisateur connecté

# CODE SÉCURISÉ (ce que ça devrait être)
def get_invoice(request, invoice_id):
    if not request.user.is_authenticated:
        return "Veuillez vous connecter"

    # Vérification : Cette facture appartient-elle à cet utilisateur ? ✓
    invoice = Invoice.objects.get(id=invoice_id, owner=request.user)
    return invoice.data  # Retourne uniquement les factures de l'utilisateur

Pourquoi c'est si courant : La logique d'autorisation doit être implémentée pour chaque endpoint. En manquer un, et vous avez un IDOR. Dans les grandes applications avec des centaines d'endpoints, les développeurs en manquent inévitablement certains. IDOR est constamment dans le Top 10 OWASP parce que c'est facile à créer et facile à trouver.

Qu'est-ce que c'est et pourquoi c'est important ?

Open Redirect — Une application accepte une URL contrôlée par l'utilisateur et redirige vers elle sans validation. En soi, cela semble inoffensif, mais ça permet de vraies attaques :

• Phishing : Envoyer les victimes vers banque-confiance.com/login?redirect=site-malveillant.com. Ils voient le domaine de confiance, cliquent, et atterrissent sur une fausse page de connexion qui vole leurs identifiants.
• Vol de tokens OAuth : Si la redirection se produit pendant la connexion OAuth, les attaquants peuvent voler les tokens d'authentification en redirigeant vers leur serveur.
• Contournement des contrôles de sécurité : Certains outils de sécurité ajoutent le domaine de confiance en liste blanche mais ne valident pas les paramètres de redirection.

Pourquoi les programmes l'acceptent : Tous les programmes ne paient pas pour les open redirects. Beaucoup exigent une démonstration d'impact (chaîné avec vol OAuth, utilisé dans un scénario de phishing réel). Vérifiez toujours la politique du programme - certains excluent explicitement les "redirections non validées" sans chaînage.

Conseil pour démontrer l'impact : Beaucoup de programmes rejettent les open redirects sans preuve d'impact. Dans votre rapport, expliquez l'attaque spécifique : "Un attaquant pourrait utiliser cette redirection pour voler des tokens OAuth pendant le flux de connexion, menant à une prise de compte." Ou démontrez un scénario de phishing avec des captures d'écran.

Ce qui paie vs ce qui ne paie pas

Toutes les divulgations d'informations ne se valent pas. Les programmes se soucient des informations qui peuvent être utilisées pour d'autres attaques ou nuisent directement aux utilisateurs :

Paie bien (Impact élevé) :

• Clés API avec accès en écriture — Clés AWS, clés Stripe, credentials cloud
• Credentials de base de données — Même si vous ne pouvez pas vous connecter, l'exposition est critique
• PII des utilisateurs — Emails, adresses, numéros de téléphone fuitant
• Code source — Surtout s'il contient des secrets codés en dur
• Tokens d'authentification internes — Secrets JWT, clés de signature de session

Peut payer (Impact moyen) :

• Adresses IP internes — Utiles pour d'autres attaques
• Endpoints de debug — S'ils exposent des données sensibles
• Stack traces avec chemins sensibles — Révèlent la structure interne

Ne paie généralement pas (Impact faible/nul) :

• Numéros de version de logiciel seuls (sans vulnérabilités connues)
• Messages d'erreur génériques
• Adresses email déjà publiques
• "Vous utilisez nginx" sans impact sécurité

Comment fonctionne le subdomain takeover

Le subdomain takeover se produit quand :

1. Une entreprise configure blog.entreprise.com pointant vers Heroku, GitHub Pages ou similaire
2. Elle arrête d'utiliser le service et supprime l'app, mais oublie de supprimer l'enregistrement DNS
3. Le sous-domaine pointe toujours vers le service, mais personne n'a revendiqué cette ressource
4. Un attaquant crée un compte sur le service et revendique ce nom de ressource
5. Maintenant l'attaquant contrôle le contenu sur blog.entreprise.com !

Impact : Les attaquants peuvent servir des pages de phishing, voler des cookies (si le sous-domaine est approuvé par le domaine parent), héberger des malwares et endommager la réputation - tout en semblant provenir de l'entreprise légitime.

🏆 500$ pour IDOR sur endpoint de facture

Le chasseur a remarqué des URLs comme /api/invoices/12345 en téléchargeant sa propre facture. Il a changé l'ID en 12346 et a reçu la facture d'un autre client - complète avec nom, adresse et historique d'achats.

Technique : A changé un nombre dans l'URL. Nécessitait deux comptes de test et 5 minutes de test. La vulnérabilité était triviale à trouver mais avait un vrai impact sur la vie privée des clients.

🏆 300$ pour clé API Stripe exposée

En cherchant dans les bundles JavaScript, le chasseur a trouvé une clé API Stripe commençant par sk_live_. La clé avait des permissions d'écriture - un attaquant aurait pu créer des débits frauduleux ou accéder aux données de paiement des clients.

Technique : Outils dev navigateur → Sources → Rechercher "sk_live". La clé était codée en dur dans un bundle webpack. A pris 10 minutes à trouver.

🏆 1000$ pour open redirect dans le flux OAuth

La connexion OAuth avait un paramètre redirect_uri qui acceptait n'importe quelle URL. Le chasseur a démontré qu'un attaquant pouvait créer un lien qui, après une connexion réussie, redirigerait l'utilisateur (et son token d'authentification) vers un serveur contrôlé par l'attaquant.

Technique : A identifié le flux OAuth, testé le paramètre redirect_uri avec un domaine externe. La chaîne open redirect → vol de token → prise de compte a élevé ceci de P4 à P2.

Ça semble trop simple. Est-ce que ça paie vraiment ?

Oui. IDOR est constamment la vulnérabilité API #1 parce qu'elle est partout. Les développeurs doivent implémenter des vérifications d'autorisation pour chaque endpoint - en manquer un et vous avez un IDOR. Les bugs simples avec un vrai impact paient de vraies récompenses. Ne compliquez pas trop votre approche - commencez par chercher les problèmes évidents. Au fur et à mesure que vous gagnez en expérience, vous développerez un œil pour les variations plus subtiles.

Et si je ne peux trouver que des bugs de faible sévérité ?

Les bugs de faible sévérité paient quand même, construisent votre réputation et vous apprennent comment l'application fonctionne. Beaucoup de chasseurs chaînent plusieurs bugs de faible sévérité pour créer un impact plus élevé. Un open redirect seul peut être P4, mais chaînez-le avec un vol de token OAuth et ça devient P2. Trouver des P4 est la façon d'apprendre à trouver des P1.

Comment savoir si un IDOR est dans le scope ?

Utilisez deux comptes que vous contrôlez - n'accédez jamais aux données appartenant à de vrais utilisateurs. Votre test devrait être : "Le Compte A peut-il accéder aux données du Compte B ?" où les deux comptes sont les vôtres. Si vous trouvez un IDOR, signalez-le immédiatement. N'énumérez pas les données d'autres utilisateurs et ne téléchargez rien au-delà de ce qui est nécessaire pour prouver que le bug existe.

Mon rapport d'open redirect a été fermé comme "informatif". Pourquoi ?

Beaucoup de programmes ne paient pas pour les open redirects sans impact démontré. Dans votre rapport, expliquez le scénario d'attaque : phishing, vol de token OAuth ou contournement des contrôles de sécurité. Si c'est utilisé dans un flux OAuth, soulignez le potentiel de vol de token. Certains programmes ne l'accepteront toujours pas - vérifiez leur politique avant d'investir du temps.