hakluke/bug-bounty-standardsUn elenco di casi limite che si verificano nei programmi bug bounty, con discussioni su come dovrebbero essere gestiti. L'obiettivo è standardizzare il modo in cui le situazioni specifiche vengono gestite nei bug bounty.
Questo repository è un elenco di situazioni che si verificano nei programmi di bug bounty e di come dovrebbero essere gestite. Molte di queste sono attualmente gestite caso per caso, il che porta a molta incertezza e frustrazione per hacker, proprietari dei programmi e piattaforme. L'obiettivo di questo repository è standardizzare il modo in cui questi casi limite vengono gestiti in tutte le piattaforme e i programmi di bounty. Si spera che la standardizzazione consenta alle aspettative di essere soddisfatte più frequentemente da tutte le parti.
Questo documento è una bozza e non è ancora implementato da alcuna piattaforma di bug bounty. In questa fase, chiedo commenti a tutte le parti interessate.
Contribuisci aprendo issue su GitHub. Tutte le issue ragionevoli presentate rimarranno aperte per un minimo di 30 giorni per i commenti.
La tua issue dovrebbe esprimere un'opinione, ad es.
I commenti sulla issue sono benvenuti da chiunque, ma devono essere costruttivi e privi di emozioni. Il comportamento abusivo non sarà tollerato.
| ID | Situazione | Risoluzione |
|---|---|---|
| 1 | L'hacker invia una vulnerabilità con prova di sfruttamento. La vulnerabilità viene corretta prima che l'invio venga triage. | La piattaforma deve fornire la prova che l'invio non è stato consultato dal programma prima della risoluzione. Se l'invio è stato consultato dal programma, il programma dovrebbe pagare la relativa taglia, altrimenti l'invio viene marcato come duplicato. |
| 2 | L'hacker invia una vulnerabilità e il programma risponde dicendo che ne era già a conoscenza internamente. | Il programma deve fornire la prova che si trattava di un problema precedentemente noto, ad esempio uno screenshot di un ticket Jira con la data di creazione. Se il programma non è in grado di fornire una prova, dovrebbe pagare la taglia, altrimenti l'invio dovrebbe essere marcato come duplicato. |
| 3 | L'hacker invia una vulnerabilità che viene marcata come duplicato di un altro invio che non ha esplorato completamente l'impatto del bug. Ad esempio, un hacker invia una XSS completa che consente l'account takeover e viene duplicata rispetto a un altro invio che ha segnalato solo HTML injection. | Il primo reporter riceve una taglia basata sull'impatto del proprio invio, il secondo reporter riceve una taglia basata sull'impatto del proprio invio meno la taglia ricevuta dal primo reporter. |
| 4 | L'hacker invia una vulnerabilità e il programma non risponde mai. | La piattaforma paga la taglia. |
| 5 | L'hacker invia una vulnerabilità e viene erroneamente duplicato rispetto a una segnalazione più recente. | La piattaforma modifica lo stato di entrambe le segnalazioni per renderlo accurato. Se il pagamento è già stato effettuato in modo errato, l'organizzazione che ha eseguito il triage in modo errato paga la taglia. Per i programmi di bounty gestiti questa sarebbe generalmente la piattaforma, ma per i programmi non gestiti sarebbe il programma. |
| 6 | L'hacker non è d'accordo sulla gravità assegnata. | L'hacker invia le motivazioni nel ticket. Se non c'è risposta per 14 giorni, l'hacker invia le motivazioni al canale di supporto della piattaforma. Gli upgrade di gravità vengono decisi caso per caso. |
| 7 | L'hacker divulga pubblicamente un bug che è stato precedentemente inviato alla piattaforma, senza il permesso esplicito del proprietario del programma. | Un ricercatore dovrebbe essere in grado di divulgare pubblicamente la vulnerabilità nelle seguenti circostanze: a) Il bug non è stato accettato come valido, cioè è stato marcato come N/A o Informativo. b) Il bug si trova in uno stato risolto da 30+ giorni. c) Il ricercatore ha il permesso esplicito dal programma di divulgarli pubblicamente. In altri casi, l'hacker riceve un ban di 30 giorni dalla piattaforma e viene contattato via email con le motivazioni complete del ban. La reiterazione del reato comporta il ban permanente. |
| 8 | L'hacker invia un bug che è nel perimetro del programma, ma in realtà è un bug in un servizio di terze parti. | Ogni programma dovrebbe specificare se accetta bug su sistemi di terze parti nel proprio brief. Se non c'è specifica, allora si presume che TUTTI i sistemi elencati nel perimetro siano validi per il pagamento, inclusi i sistemi di terze parti. |
| 9 | L'hacker invia una vulnerabilità zero-day senza exploit pubblici o divulgazioni esistenti, che colpisce sistemi nel perimetro. | Se sono state apportate modifiche a seguito della segnalazione, ad esempio modifiche alla configurazione, messa offline di sistemi o applicazione di regole WAF, la segnalazione dovrebbe essere accettata e premiata. Va fatta una distinzione tra exploit zero-day pubblici e exploit zero-day che il tuo team non avrebbe conosciuto se non fosse stato per la segnalazione di bug bounty. |
| 10 | L'hacker invia un bug a un programma che ha un brief con perimetro aperto. Il bug riguarda un'acquisizione. Il proprietario del programma non controlla l'infrastruttura IT o il personale dell'acquisizione. | Il proprietario del programma dovrebbe compiere uno sforzo in buona fede, verificato dalla piattaforma, per informare l'acquisizione. Qualora l'acquisizione traesse beneficio dall'invio, il proprietario del programma dovrebbe pagare la taglia. Il brief dovrebbe essere aggiornato per riflettere se le acquisizioni sono nel perimetro. |
