Programma di ricompensa per bug

Capgo si impegna per la sicurezza e la trasparenza. Tutti i nostri code sono open source, e accogliamo i ricercatori di sicurezza per aiutarci a identificare le vulnerabilità nel nostro codice.

Sorgente Aperta Code

Ogni repository nell'organizzazione Capgo è open source. Puoi esaminare, auditare e contribuire ai nostri code.

Organizzazione GitHub github.com/Cap-go

Capgo Backend & Landing

Repository principale Capgo che include servizi backend e sito web di presentazione

Visualizza Repository Segnala Problema di Sicurezza

Capacitor Aggiornamento Plugin

Il plugin di base Capacitor che gestisce gli aggiornamenti in tempo reale su dispositivi mobili

Visualizza Repository Segnala Problema di Sicurezza

Requisiti per i Rapporti Validi

Per qualificarsi per il programma Bug Bounty, il tuo rapporto deve soddisfare TUTTI i seguenti requisiti:

Devi identificare l'esatto file e il numero di riga del nostro repository GitHub dove esiste la vulnerabilità
Il tuo rapporto deve essere inviato attraverso GitHub Advisory di Sicurezza sul repository pertinente
Devi includere una descrizione chiara della vulnerabilità e del suo impatto potenziale
Devi fornire passaggi riproducibili per dimostrare l'issue

Importante: Se non puoi fornire la riga esatta di code in GitHub dove il problema esiste, il tuo rapporto non sarà eleggibile per il programma Bug Bounty. I rapporti devono essere inviati attraverso GitHub Security Advisory solo. I pagamenti sono gestiti da Algora.io; per favore crea un account lì affinché possiamo pagarti direttamente sulla piattaforma.

Tempo di Risposta e Rispetto

Siamo amichevoli e paghiamo per i rapporti validi, ma non possiamo lavorare con persone che non rispettano il nostro tempo. Per favore mantieni la comunicazione calma e segui questo programma.

Rispondiamo ai rapporti di sicurezza e alle violazioni entro 24-72 ore.
Non ci spammare. Più di tre email in un solo giorno è considerato spam e verrà bloccato.
Non paghiamo per i rapporti che ignorano queste regole o sono spam.
Solo i rapporti in-scope che seguono questo programma di bug bounty sono accettati; qualsiasi altra cosa potrebbe essere bloccata.
Non chiedere aggiornamenti sullo stato come "hai controllato?" o domande simili. Una volta che confermiamo di aver ricevuto il tuo rapporto, basta così. Dopo di che, ci sono ancora molte cose da fare, e preparare una richiesta di pull può richiedere diversi giorni.

Importante: Capgo è una piccola azienda auto-sostenuta, quindi i nostri importi di borsa sono inferiori rispetto ai programmi delle grandi aziende. I rapporti senza un percorso chiaro di sfruttamento sono pagati fino a $30 massimo. Gli sfruttamenti con un impatto reale e riproducibile su Capgo sono pagati fino a $300 massimo. Accettiamo e revisioniamo i rapporti di sicurezza per i plugin Capgo, ma i bounties pagati per i plugin code sono limitati a @capgo/capacitor-aggiornatore. Altri plugin Capgo sono gratuiti e non fanno parte della nostra offerta di prodotto pagata, quindi i rapporti su di essi vengono revisionati ma non sono pagati. Le pagamenti vengono emessi solo dopo che abbiamo identificato il problema, lo abbiamo risolto, abbiamo aperto una richiesta di pull e tu hai verificato dopo la rilascio che la correzione funziona per te. Questo processo solitamente dura tra i 20 e i 30 giorni. Per favore, non inviare messaggi come "per ricevere il pagamento"; il pagamento avviene solo una volta che il rilascio è live e hai testato e validato la correzione.

Come segnalare

Naviga al repository relativo su GitHub
Clicca sulla scheda "Security"
Clicca su "Segnala una vulnerabilità" per creare un nuovo avviso di sicurezza
Includi il percorso file esatto e il numero di riga (o righe) dove la vulnerabilità esiste
Fornisci passaggi dettagliati per riprodurre l'errore e spiega l'impatto di sicurezza

Fuori Scopo

Rapporti senza riferimenti di riga code esatti in GitHub
Rapporti non inviati attraverso GitHub Security Advisory
Vulnerabilità teoriche senza prova di concetto
Bug in piattaforme, dipendenze o servizi terzi che Capgo non può risolvere direttamente (segnaletica quelli upstream, ad esempio a Supabase)
tentativi di ingegneria sociale o phishing
attacchi di servizio
relazioni di SSRF o DNS spoofing contro webhook o anteprima del sito web. Queste funzionalità eseguono un'infrastruttura senza server e non possono essere utilizzate per raggiungere l'infrastruttura Capgo privata, quindi non sono esploitabili nel nostro ambiente.
configurazione dell'applicazione o del progetto code di proprietà dell'utente che Capgo non possiede, non spedisce o non controlla, inclusi file come capacitor.config.ts, config.capacitor.ts, sorgenti dell'applicazione code e impostazioni specifiche per l'ambiente.
accesso ai file del pacchetto Capgo o la prova che i file del pacchetto possono essere scaricati. I file del pacchetto sono asset web pubblici, gli utenti sono informati di questo e l'accesso a loro non è considerato una violazione dei dati.

Supabase e Servizi Terzi

Se la causa radice è un bug o un problema di servizio della piattaforma Supabase, segnalarlo a Supabase, non a Capgo. Se la logica vulnerabile, SQL, RPC, politica RLS, funzione Edge o configurazione è stata creata o scelta da Capgo e possiamo risolverla nel nostro progetto, è in ambito anche quando Supabase serve l'endpoint. Per le informazioni relative al comportamento di Supabase stesso, includere un caso riproducibile e il cambiamento di impostazione o configurazione Supabase esatto che lo prevenirebbe in un progetto configurato come il nostro.

Esempi

Non valido qui

Un bug, un'interruzione o un comportamento della piattaforma Supabase che solo Supabase può risolvere
Un ritrovamento che non si può riprodurre
Una pretesa che incolpa Capgo per il comportamento di Supabase senza mostrare una correzione Capgo-controllata o il cambiamento di impostazione/configurazione Supabase esatto

Efficace qui

Una configurazione Supabase controllata da Capgo che possiamo risolvere nelle impostazioni del nostro progetto (con passaggi)
Una questione di SQL, RPC, RLS, funzione o integrazione di proprietà di Capgo che causa un utilizzo Supabase non sicuro
Una questione riproducibile nel progetto Supabase di Capgo, schema o politiche, anche se è esposta attraverso un endpoint Supabase

Limitazioni note di Autenticazione Supabase (Già segnalate)

Alcune scoperte sono segnalate ripetutamente e sono causate dalle impostazioni predefinite di Autenticazione Supabase o dal comportamento della piattaforma piuttosto che da Capgo code. Rivediamo queste solo quando possono essere riprodotte in un progetto demo Supabase condiviso configurato come il nostro e quando la correzione è un cambiamento di configurazione Supabase da parte del lato server che non richiede modifiche alle regole di sicurezza di Capgo. Se la correzione richiede modifiche a SQL, RPC, politiche RLS, funzioni o logica dell'app di Capgo, segnalarlo a noi perché è in ambito.

Fornisci un caso riproducibile e identifica la correzione esatta: o il cambiamento di impostazione/configurazione Supabase che risolve un problema di comportamento Supabase, o l'oggetto Capgo-di proprietà code/config che deve cambiare.
Il comportamento della verifica dell'indirizzo e-mail è previsto che segua le impostazioni del progetto di Autenticazione Supabase (ad esempio, se la conferma dell'indirizzo e-mail è disabilitata e si utilizza l'autenticazione basata sulla cattura)
Il flusso di aggiornamento della password e di recupero della registrazione potrebbe non richiedere sempre la reimmissione della vecchia password o la ri-asserzione se l'Autenticazione Supabase è configurata in quel modo.
Se l'issue è in questa lista ma puoi fornire una soluzione concreta da Supabase nel progetto fornito o un difetto di sicurezza concreto di proprietà Capgo, possiamo considerarlo nell'ambito.

Per domande sul nostro programma di Bug Bounty, per favore contattaci attraverso le nostre GitHub Security Advisories.