hakluke/bug-bounty-standardsUne liste de cas limites qui se produisent dans les programmes de bug bounty, avec des discussions sur la manière de les traiter. L'objectif est de standardiser la façon dont les situations spécifiques sont gérées dans les bug bounties.
Ce dépôt est une liste de situations qui se produisent dans les programmes de bug bounty et de la manière dont elles devraient être traitées. Beaucoup de ces situations sont actuellement traitées au cas par cas, ce qui entraîne beaucoup d'incertitude et de frustration chez les hackers, les propriétaires de programmes et les plateformes. L'objectif de ce dépôt est de normaliser la manière dont ces cas limites sont traités sur toutes les plateformes et tous les programmes de bug bounty. Espérons que la normalisation permettra de répondre plus fréquemment aux attentes de toutes les parties.
Ce document est un brouillon et n'est pas encore mis en œuvre par les plateformes de bug bounty. À ce stade, je demande des commentaires à toutes les parties intéressées.
Veuillez contribuer en ouvrant des issues GitHub. Toutes les issues raisonnables soumises resteront ouvertes pendant un minimum de 30 jours pour commentaires.
Votre issue doit exprimer une opinion, par exemple :
Les commentaires sur l'issue sont les bienvenus de la part de tous, mais doivent être constructifs et sans émotion. Les comportements abusifs ne seront pas tolérés.
| ID | Situation | Résolution |
|---|
| 1 | Un hacker soumet une vulnérabilité avec une preuve d'exploitation. La vulnérabilité est corrigée avant que la soumission ne soit triée. | La plateforme doit fournir la preuve que la soumission n'a pas été consultée par le programme avant la résolution. Si la soumission a été consultée par le programme, le programme doit payer la prime correspondante, sinon la soumission est marquée comme doublon. |
| 2 | Un hacker soumet une vulnérabilité, le programme répond qu'il en avait déjà connaissance en interne. | Le programme doit fournir la preuve qu'il s'agissait d'un problème déjà connu, par exemple, une capture d'écran d'un ticket Jira incluant la date de création. Si le programme ne peut pas fournir de preuve, il doit payer la prime, sinon la soumission doit être marquée comme doublon. |
| 3 | Un hacker soumet une vulnérabilité, elle est marquée comme doublon d'une autre soumission qui n'a pas pleinement exploré l'impact du bug. Par exemple, un hacker soumet un XSS complet qui permet une prise de contrôle de compte, et elle est dupliquée avec une autre soumission qui n'a signalé qu'une injection HTML. | Le premier rapporteur reçoit une prime basée sur l'impact de sa soumission, le deuxième rapporteur reçoit une prime basée sur l'impact de sa soumission moins la prime reçue par le premier rapporteur. |
| 4 | Un hacker soumet une vulnérabilité, le programme ne répond jamais. | La plateforme paie la prime. |
| 5 | Un hacker soumet une vulnérabilité, le hacker est incorrectement dupliqué avec un rapport plus récent. | La plateforme modifie le statut des deux rapports pour qu'il soit exact. Si un paiement a déjà été effectué par erreur, l'organisation qui a effectué le tri de manière incorrecte paie la prime. Pour les programmes de bug bounty gérés, il s'agirait généralement de la plateforme, mais pour les programmes non gérés, il s'agirait du programme. |
| 6 | Le hacker n'est pas d'accord avec la note de gravité attribuée. | Le hacker soumet son raisonnement au ticket. S'il n'y a pas de réponse sous 14 jours, le hacker soumet son raisonnement au canal de support de la plateforme. Les augmentations de gravité sont décidées au cas par cas pour chaque soumission. |
| 7 | Un hacker divulgue publiquement un bug qui a été précédemment soumis à la plateforme, sans autorisation explicite du propriétaire du programme. | Un chercheur devrait pouvoir divulguer publiquement la vulnérabilité dans les circonstances suivantes : a) Le bug n'a pas été accepté comme valide, c'est-à-dire qu'il a été marqué comme N/A ou Informatif. b) Le bug est dans un état résolu depuis plus de 30 jours. c) Le chercheur a l'autorisation explicite du programme de divulguer publiquement. Dans les autres cas, le hacker reçoit une interdiction de 30 jours sur la plateforme, le hacker reçoit un e-mail avec toutes les raisons de l'interdiction. Une récidive entraîne une interdiction permanente. |
| 8 | Un hacker soumet un bug qui est dans le périmètre du programme, mais qui est en réalité un bug dans un service tiers. | Chaque programme doit préciser s'il accepte les bugs sur les systèmes tiers dans son brief. S'il n'y a pas de spécification, il est alors supposé que TOUS les systèmes listés dans le périmètre seront valables pour le paiement, y compris les systèmes tiers. |
| 9 | Un hacker soumet une vulnérabilité zero-day sans exploits publics ni divulgation existante, affectant des systèmes dans le périmètre. | Si des changements ont été effectués à la suite du rapport, c'est-à-dire des modifications de configuration, la mise hors ligne de systèmes ou l'application de règles WAF, le rapport doit être accepté et récompensé. Une distinction doit être faite entre les exploits zero-day publics et les exploits zero-day que votre équipe n'aurait pas connus sans le rapport de bug bounty. |
| 10 | Un hacker soumet un bug à un programme qui a un brief de périmètre ouvert. Le bug concerne une acquisition. Le propriétaire du programme ne contrôle pas l'infrastructure informatique ni le personnel de l'acquisition. | Le propriétaire du programme doit faire un effort de bonne foi, vérifié par la plateforme, pour informer l'acquisition. Si l'acquisition bénéficie de la soumission, le propriétaire du programme doit payer la prime. Le brief doit être mis à jour pour refléter si la ou les acquisitions sont dans le périmètre. |
