Saltare al contenuto principale
Capgo logo

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.

Open Source Code

Tutti i repository dell'organizzazione Capgo sono open source. Puoi esaminare, auditare e contribuire ai nostri code.

Organizzazione GitHub: github.com/Cap-go

Backend e Sito Web Capgo

Repository principale di Capgo che include i servizi backend e il sito web di lancio

Visualizza Repository Segnala Problema di Sicurezza

Plugin di Aggiornamento Capacitor

Il plugin di Capacitor core che gestisce gli aggiornamenti in tempo reale sui dispositivi mobili

Visualizza Repository Segnala Problema di Sicurezza

Requisiti per Relazioni Valide

Per qualificarsi per il programma Bug Bounty, la tua relazione deve soddisfare TUTTI i seguenti requisiti:

  • Devi identificare il file e il numero di riga esatto nel nostro repository GitHub dove esiste la vulnerabilità
  • La tua relazione deve essere inviata 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'errore

Importante: Se non puoi fornire la riga esatta di code in GitHub dove esiste il problema, la tua relazione non sarà eleggibile per il programma Bug Bounty. Le relazioni devono essere inviate attraverso GitHub Advisory di Sicurezza 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 le relazioni valide, ma non possiamo lavorare con persone che non rispettano il nostro tempo. Per favore mantieni la comunicazione calma e segui questo programma.

  • Rispondiamo a rapporti di sicurezza e 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.
  • Sono accettati solo i rapporti in-scope che seguono questo programma di bug bounty; qualsiasi altra cosa può essere bloccata.
  • Non chiedere aggiornamenti sullo stato come "avete controllato?" o domande simili. Una volta che confermiamo di aver ricevuto il tuo rapporto, è sufficiente. Dopo di che, c'è ancora molto lavoro da fare, e preparare una richiesta di pull può richiedere diversi giorni.

Importante: Capgo è una piccola azienda bootstrappata, quindi gli importi della nostra borsa sono inferiori rispetto ai programmi delle grandi aziende. I rapporti senza un percorso di sfruttamento chiaro 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 le borse pagate per i plugin code sono limitate a @capgo/capacitor-aggiornatore. Gli altri plugin Capgo sono gratuiti e non fanno parte della nostra offerta di prodotto pagata, quindi i rapporti per loro vengono revisionati ma non pagati. I 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 release che la correzione funziona per te. Questo processo solitamente richiede tra i 20 e i 30 giorni. Per favore, non inviare messaggi come "per ricevere il pagamento"; il pagamento avviene solo una volta che la release è live e hai testato e validato la correzione.

Come segnalare un problema

  1. Naviga al repository relativo su GitHub
  2. Seleziona la scheda "Security"
  3. Clicca su "Segnalazione di vulnerabilità" per creare un nuovo avviso di sicurezza
  4. Includi il percorso file esatto e il numero di riga (le) dove esiste la vulnerabilità
  5. Fornisci passaggi dettagliati per riprodurre l'errore e spiega l'impatto sulla sicurezza

Fuori Scopo

  • Reports without exact code line references in GitHub
  • Rapporti non inviati attraverso GitHub Security Advisory
  • Vulnerabilità teoriche senza prova di concetto
  • Bugs in piattaforme, dipendenze o servizi di terze parti che Capgo non può risolvere direttamente (segnaletica quelli upstream, ad esempio a Supabase).
  • Tentativi di ingegneria sociale o di phishing
  • Attacchi di servizio
  • Rapporti di SSRF o DNS spoofing contro webhook o anteprima del sito web. Queste funzionalità eseguono infrastruttura serverless 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, distribuisce o controlla, inclusi file come capacitor.config.ts, config.capacitor.ts, codice sorgente code e impostazioni specifiche dell'ambiente.
  • Accesso ai file del pacchetto Capgo o 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 di Terze Parti

Se la causa radice è un bug o un problema del servizio della piattaforma Supabase, segnalarlo a Supabase, non a Capgo. Se la logica vulnerabile, SQL, RPC, politica RLS, Funzione di Edge o la configurazione è stata creata o scelta da Capgo e possiamo risolverla nel nostro progetto, è in ambito anche quando Supabase gestisce l'endpoint. Per le trovate relative al comportamento di Supabase stesso, includere un caso riproducibile e la configurazione Supabase esatta o il cambiamento di configurazione 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
  • Una trovata che non si può riprodurre
  • Una pretesa che incolpa Capgo per il comportamento di Supabase senza mostrare una correzione Capgo-controllata o la configurazione Supabase esatta/configurazione di cambiamento

Valido qui

  • Una configurazione Supabase errata Capgo-controllata che possiamo risolvere nelle impostazioni del nostro progetto (con passaggi)
  • Un problema Capgo-di proprietà SQL, RPC, RLS, funzione o integrazione che causa un utilizzo Supabase non sicuro
  • A problema riproducibile nella Capgo del progetto Supabase, schema o politiche, anche se è esposto attraverso un endpoint Supabase

Limitazioni note di Autenticazione Supabase (Già segnalate)

Alcune scoperte vengono 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 che non richiede modifiche alle regole di sicurezza Capgo. Se il cambiamento richiede modifiche alle regole SQL, RPC, RLS, funzioni o logica dell'app di Capgo, segnalarlo a noi perché è in ambito.

  • Provide a reproducible case and identify the exact fix: either the Supabase setting/config change that resolves a Supabase behavior issue, or the Capgo-owned code/config object that must change.
  • Il comportamento di verifica dell'e-mail è previsto che segua le impostazioni del progetto Autenticazione Supabase (ad esempio, se la conferma dell'e-mail è disabilitata e si utilizza l'autenticazione basata sulla cattura).
  • Il flusso di aggiornamento della password e la ripristinazione dell'account possono non richiedere sempre la rientro dell'antico password o la riconferma se Autenticazione Supabase è configurata in questo modo.
  • Se il problema è in questa lista ma puoi mostrare una correzione concreta da parte di Supabase nel progetto fornito o un difetto di sicurezza Capgo-posseduto, possiamo considerarlo in ambito.

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