Que fait Chasseur de Prime de Sécurité ?
Utilisez ceci lorsque l'objectif est la découverte pratique de vulnérabilités pour une divulgation responsable ou une soumission de prime, et non une revue générale des bonnes pratiques.
Quand l'utiliser
- Analyser un dépôt à la recherche de vulnérabilités exploitables
- Préparer une soumission pour Huntr, HackerOne, ou un programme similaire
- Triage où la question est « est-ce que ça rapporte vraiment ? » plutôt que « est-ce que c'est théoriquement dangereux ? »
Comment ça fonctionne
Favorise les vecteurs d'attaque accessibles à distance et contrôlés par l'utilisateur, et écarte les schémas que les plateformes rejettent systématiquement comme informatifs ou hors scope.
Schémas dans le scope
Ce sont les types de problèmes qui comptent vraiment :
| Schéma | CWE | Impact typique |
|---|---|---|
| SSRF via des URL contrôlées par l'utilisateur | CWE-918 | Accès au réseau interne, vol de métadonnées cloud |
| Contournement d'authentification dans les middlewares ou gardiens API | CWE-287 | Accès non autorisé aux comptes ou aux données |
| Désérialisation distante ou chemins upload-to-RCE | CWE-502 | Exécution de code |
| Injection SQL dans des points d'accès atteignables | CWE-89 | Exfiltration de données, contournement d'authentification, destruction de données |
| Injection de commandes dans les gestionnaires de requêtes | CWE-78 | Exécution de code |
| Traversée de chemin dans les chemins de fichiers servis | CWE-22 | Lecture ou écriture de fichiers arbitraire |
| XSS auto-déclenché | CWE-79 | Vol de session, compromission de l'administrateur |
Ignorer ces schémas
Ceux-ci sont généralement à faible signal ou hors scope des primes, sauf indication contraire du programme :
pickle.loads,torch.loadou équivalent local uniquement sans chemin distanteval()ouexec()dans un outil en ligne de commande uniquementshell=Truesur des commandes entièrement codées en dur- En-têtes de sécurité manquants seuls
- Plaintes génériques de limite de débit sans impact d'exploitation
- XSS auto-infligé nécessitant que la victime colle du code manuellement
- Injection CI/CD qui ne fait pas partie du scope du programme cible
- Code de démonstration, d'exemple ou de test uniquement
Flux de travail
- Vérifier d'abord le scope : règles du programme, SECURITY.md, canal de divulgation et exclusions.
- Trouver les points d'entrée réels : gestionnaires HTTP, uploads, tâches d'arrière-plan, webhooks, analyseurs et points d'intégration.
- Exécuter des outils statiques là où cela aide, mais les traiter uniquement comme une entrée de triage.
- Lire le chemin de code réel de bout en bout.
- Prouver que le contrôle utilisateur atteint un puits significatif.
- Confirmer l'exploitabilité et l'impact avec la plus petite preuve de concept (PoC) sécurisée possible.
- Vérifier les doublons avant de rédiger un rapport.
Exemple de boucle de triage
semgrep --config=auto --severity=ERROR --severity=WARNING --json
Puis filtrer manuellement :
- supprimer les tests, démos, fixtures, code vendu
- supprimer les chemins locaux uniquement ou non atteignables
- ne garder que les résultats avec un chemin réseau ou utilisateur clair
Structure du rapport
## Description
[Quelle est la vulnérabilité et pourquoi elle est importante]
## Code vulnérable
[Chemin du fichier, plage de lignes et un petit extrait]
## Preuve de concept
[Requête ou script minimal fonctionnel]
## Impact
[Ce que l'attaquant peut accomplir]
## Version concernée
[Version, commit ou cible de déploiement testée]
Porte de qualité
Avant de soumettre :
- Le chemin de code est atteignable depuis un véritable utilisateur ou une frontière réseau
- L'entrée est réellement contrôlée par l'utilisateur
- Le puits est significatif et exploitable
- La PoC fonctionne
- Le problème n'est pas déjà couvert par un avis, un CVE ou un ticket ouvert
- La cible est effectivement dans le scope du programme de primes