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 pas une revue large des bonnes pratiques.
Quand l'Utiliser
- Scanner un dépôt à la recherche de vulnérabilités exploitables
- Préparer une soumission de prime Huntr, HackerOne, ou similaire
- Trier les questions du type « est-ce que cela paie réellement ? » plutôt que « est-ce que c'est théoriquement dangereux ? »
Comment ça Marche
Favorisez les chemins d'attaque accessibles à distance et contrôlés par l'utilisateur, et jetez les motifs que les plateformes rejettent systématiquement comme informatifs ou hors scope.
Motifs Éligibles
Voici les types de problèmes qui comptent régulièrement :
| Motif | 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 le middleware ou les gardes d'API | CWE-287 | Accès non autorisé aux comptes ou aux données |
| Désérialisation à distance ou chemins de téléversement vers RCE | CWE-502 | Exécution de code |
| Injection SQL dans des points de terminaison accessibles | 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 service de fichiers | CWE-22 | Lecture ou écriture arbitraire de fichiers |
| XSS auto-déclenché | CWE-79 | Vol de session, compromission administrateur |
Ignorer Ceux-ci
Ceux-ci sont généralement à faible signal ou hors scope des primes, sauf si le programme en dit autrement :
pickle.loads,torch.load, ou équivalents uniquement locaux sans chemin distanteval()ouexec()dans un outil uniquement en ligne de commandeshell=Truesur des commandes entièrement codées en dur- Absence d'en-têtes de sécurité seuls
- Plaintes génériques sur la limitation de débit sans impact d'exploitation
- XSS auto-infligé nécessitant que la victime colle manuellement du code
- Injection CI/CD qui ne fait pas partie du scope du programme cible
- Code de démonstration, d'exemple ou de test uniquement
Workflow
- Vérifiez d'abord le scope : règles du programme, SECURITY.md, canal de divulgation et exclusions.
- Trouvez les points d'entrée réels : gestionnaires HTTP, téléversements, tâches d'arrière-plan, webhooks, analyseurs syntaxiques et points de terminaison d'intégration.
- Exécutez des outils statiques là où cela aide, mais traitez-les uniquement comme une contribution au triage.
- Lisez le chemin de code réel de bout en bout.
- Prouvez que le contrôle utilisateur atteint un puits significatif.
- Confirmez l'exploitabilité et l'impact avec le plus petit PoC sûr possible.
- Vérifiez les doublons avant de rédiger un rapport.
Exemple de Boucle de Triage
semgrep --config=auto --severity=ERROR --severity=WARNING --json
Puis filtrez manuellement :
- supprimez les tests, démos, fixtures, code vendu
- supprimez les chemins uniquement locaux ou non accessibles
- conservez uniquement les résultats avec une route réseau claire ou contrôlée par l'utilisateur
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 de travail minimal]
## Impact
[Ce que l'attaquant peut accomplir]
## Version Affectée
[Version, commit ou cible de déploiement testée]
Gate de Qualité
Avant de soumettre :
- Le chemin de code est accessible depuis un utilisateur réel ou une frontière réseau
- L'entrée est véritablement contrôlée par l'utilisateur
- Le puits est significatif et exploitable
- Le 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 prime