hakluke/bug-bounty-standardsEine Liste von Grenzfällen, die in Bug-Bounty-Programmen auftreten, sowie Gespräche darüber, wie sie behandelt werden sollten. Ziel ist es, die Handhabung bestimmter Situationen in Bug-Bounties zu standardisieren.
Dieses Repository ist eine Liste von Situationen, die in Bug-Bounty-Programmen auftreten, und wie sie behandelt werden sollten. Viele davon werden derzeit von Fall zu Fall behandelt, was bei Hackern, Programmverantwortlichen und Plattformen zu viel Unsicherheit und Frustration führt. Das Ziel dieses Repositorys ist es, die Behandlung dieser Randfälle über alle Bounty-Plattformen und -Programme hinweg zu standardisieren. Hoffentlich ermöglicht die Standardisierung, dass Erwartungen von allen Seiten häufiger erfüllt werden.
Dieses Dokument ist ein Entwurf und wurde noch von keiner Bug-Bounty-Plattform umgesetzt. In diesem Stadium bitte ich alle interessierten Parteien um Kommentare.
Bitte trage bei, indem du GitHub-Issues eröffnest. Alle eingereichten, angemessenen Issues bleiben für Kommentare mindestens 30 Tage lang offen.
Dein Issue sollte eine Meinung äußern, z. B.
Kommentare zu dem Issue sind von jedem willkommen, müssen aber konstruktiv und sachlich sein. Missbräuchliches Verhalten wird nicht toleriert.
| ID | Situation | Resolution |
|---|---|---|
| 1 | Der Hacker meldet eine Schwachstelle mit Nachweis der Ausnutzung. Die Schwachstelle wird behoben, bevor die Meldung triagiert wird. | Die Plattform muss nachweisen, dass die Meldung vor der Behebung nicht vom Programm eingesehen wurde. Falls die Meldung vom Programm eingesehen wurde, sollte das Programm die entsprechende Bounty zahlen; andernfalls wird die Meldung als Duplikat markiert. |
| 2 | Der Hacker meldet eine Schwachstelle; das Programm antwortet, dass es intern bereits davon wusste. | Das Programm muss nachweisen, dass dies ein bereits bekanntes Problem war, z. B. durch einen Screenshot eines Jira-Tickets inklusive Erstellungsdatum. Wenn das Programm keinen Nachweis erbringen kann, sollte es die Bounty zahlen; andernfalls sollte die Meldung als Duplikat markiert werden. |
| 3 | Der Hacker meldet eine Schwachstelle, die als Duplikat einer anderen Meldung markiert wird, die die Auswirkungen des Fehlers nicht vollständig untersucht hat. Beispielsweise meldet ein Hacker eine vollständige XSS, die eine Kontoübernahme ermöglicht, und wird als Duplikat einer anderen Meldung behandelt, die nur HTML-Injection gemeldet hat. | Der erste Melder erhält eine Bounty basierend auf der Auswirkung seiner Meldung; der zweite Melder erhält eine Bounty basierend auf der Auswirkung seiner Meldung abzüglich der Bounty, die der erste Melder erhalten hat. |
| 4 | Der Hacker meldet eine Schwachstelle, das Programm antwortet nie. | Die Plattform zahlt die Bounty. |
| 5 | Der Hacker meldet eine Schwachstelle, der Hacker wird fälschlicherweise als Duplikat eines neueren Berichts eingestuft. | Die Plattform ändert den Status beider Meldungen, sodass sie korrekt sind. Wenn bereits eine falsche Zahlung geleistet wurde, zahlt die Organisation, die das Triage falsch durchgeführt hat, die Bounty. Bei verwalteten Bounty-Programmen wäre dies in der Regel die Plattform, bei nicht verwalteten Programmen das Programm. |
| 6 | Der Hacker ist mit der zugewiesenen Schweregradeinstufung nicht einverstanden. | Der Hacker reicht seine Begründung im Ticket ein. Wenn 14 Tage lang keine Antwort erfolgt, reicht der Hacker die Begründung über den Support-Kanal der Plattform ein. Hochstufungen der Schweregrade werden von Fall zu Fall entschieden. |
| 7 | Der Hacker veröffentlicht einen Fehler öffentlich, der zuvor auf der Plattform eingereicht wurde, ohne ausdrückliche Genehmigung des Programmverantwortlichen. | Ein Forscher sollte die Schwachstelle unter den folgenden Umständen öffentlich offenlegen können: a) Der Fehler wurde nicht als gültig anerkannt, d. h. er wurde als N/A oder informativ markiert. b) Der Fehler befindet sich seit 30+ Tagen im Status "Gelöst". c) Der Forscher hat die ausdrückliche Genehmigung des Programms zur öffentlichen Offenlegung. In anderen Fällen erhält der Hacker eine 30-tägige Sperre von der Plattform; der Hacker wird per E-Mail mit der vollständigen Begründung der Sperre informiert. Ein erneuter Verstoß führt zu einer permanenten Sperre. |
| 8 | Der Hacker meldet einen Fehler, der in den Scope des Programms fällt, aber tatsächlich ein Fehler in einem Drittanbieterdienst ist. | Jedes Programm sollte in seiner Programmbeschreibung angeben, ob es Fehler in Drittanbietersystemen akzeptiert. Wenn es keine Angabe gibt, wird angenommen, dass ALLE im Scope aufgeführten Systeme für die Zahlung gültig sind, einschließlich Drittanbietersystemen. |
| 9 | Der Hacker meldet eine Zero-Day-Schwachstelle, für die keine öffentlichen Exploits oder Offenlegungen existieren und die Systeme im Scope betrifft. | Wenn als Ergebnis der Meldung Änderungen vorgenommen wurden, z. B. Konfigurationsänderungen, das Offline-Nehmen von Systemen oder das Anwenden von WAF-Regeln, sollte die Meldung akzeptiert und belohnt werden. Es muss unterschieden werden zwischen öffentlichen Zero-Day-Exploits und Zero-Day-Exploits, von denen Ihr Team ohne den Bug-Bounty-Bericht nichts gewusst hätte. |
| 10 | Der Hacker meldet einen Fehler an ein Programm mit einem offenen Scope-Brief. Der Fehler betrifft ein erworbenes Unternehmen. Der Programmverantwortliche hat keine Kontrolle über die IT-Infrastruktur oder das Personal des erworbenen Unternehmens. | Der Programmverantwortliche sollte in gutem Glauben, von der Plattform verifiziert, versuchen, das erworbene Unternehmen zu informieren. Sollte das erworbene Unternehmen von der Meldung profitieren, sollte der Programmverantwortliche die Bounty zahlen. Der Brief sollte aktualisiert werden, um zu berücksichtigen, ob Akquisitionen im Scope liegen. |
