Bug Bounty Programm

Capgo ist sich der Sicherheit und Transparenz verschrieben. Alle unsere code sind Open-Source und wir laden Sicherheitsforscher ein, uns bei der Identifizierung von Sicherheitslücken in unserem Codebase zu helfen.

Offene Quellcode Code

Jedes Repository in der Capgo Organisation ist Open-Source. Sie können unsere code überprüfen, auditen und beitragen.

Organisation GitHub github.com/Cap-go

Capgo Backend & Landing

Haupt Capgo Repository, einschließlich Backend-Diensten und Landing-Website

Repository anzeigen Sicherheitslücke melden

Capacitor Updater-Plugin

Das Kern- Capacitor-Plugin, das über die Luft über Updates auf mobilen Geräten handhabt

Repository ansehen Sicherheitsproblem melden

Anforderungen für gültige Berichte

Um für das Bug Bounty-Programm qualifiziert zu sein, muss Ihr Bericht alle folgenden Anforderungen erfüllen:

Sie müssen die genaue Datei und Zeilennummer in unserem GitHub-Repository angeben, an der die Schwachstelle existiert
Ihr Bericht muss über GitHub Security Advisory auf dem relevanten Repository eingereicht werden
Sie müssen eine klare Beschreibung der Schwachstelle und ihres potenziellen Auswirkungen bereitstellen
Sie müssen reproduzierbare Schritte bereitstellen, um das Problem zu demonstrieren

Wichtig: If you cannot provide the exact line of code in GitHub where the problem exists, your report will not be eligible for the Bug Bounty program. Reports must be submitted through GitHub Security Advisory only. Payments are handled via Algora.io; please create an account there so we can pay you directly on the platform.

Reaktionszeit und Respekt

Wir sind freundlich und zahlen für gültige Berichte, aber wir können nicht mit Menschen zusammenarbeiten, die unsere Zeit nicht respektieren. Bitte halten Sie die Kommunikation ruhig und folgen Sie diesem Programm.

Wir reagieren auf Sicherheitsberichte und -verletzungen innerhalb von 24-72 Stunden.
Bitte spam uns nicht. Mehr als drei E-Mails an einem Tag gilt als Spam und wird blockiert.
Wir zahlen für Berichte, die diese Regeln ignorieren oder als Spam gelten.
Nur Berichte, die diesem Bug-Bounty-Programm entsprechen, werden angenommen; anderes kann blockiert werden.
Bitte stellen Sie keine Anfragen nach Status-Updates wie "haben Sie das überprüft?" oder ähnliche Fragen. Sobald wir bestätigen, dass wir Ihren Bericht erhalten haben, ist das genug. Danach bleibt noch viel Arbeit, und die Erstellung eines Pull-Requests kann mehrere Tage dauern.

Wichtig: Capgo ist ein kleines, selbstfinanziertes Unternehmen, daher sind unsere Bountysätze niedriger als bei großen Unternehmen. Berichte ohne einen klaren Ausführungsweg werden bis zu 30 $ bezahlt. Ausführungen mit realen, reproduzierbaren Auswirkungen auf Capgo werden bis zu 300 $ bezahlt. Wir akzeptieren und überprüfen Sicherheitsberichte für Capgo-Plugins, aber bezahlte Bountys für code-Plugins sind auf @capgo/capacitor-Updater beschränkt. Andere Capgo-Plugins sind kostenlos und gehören nicht zu unserem bezahlten Produktangebot, daher werden Berichte für sie geprüft, aber unbezahlt bleiben. Zahlungen werden nur ausgestellt, nachdem wir das Problem identifiziert, es behoben, einen Pull-Request erstellt und Sie nach der Veröffentlichung bestätigt haben, dass die Reparatur funktioniert. Dieser Prozess dauert normalerweise zwischen 20 und 30 Tagen. Bitte senden Sie keine Nachrichten wie "um bezahlt zu werden"; Zahlungen erfolgen nur, wenn die Veröffentlichung live ist und Sie die Reparatur getestet und validiert haben.

Wie man einen Bericht einreicht

Navigieren Sie zum relevanten Repository auf GitHub
Klicken Sie auf die Schaltfläche "Sicherheit"
Klicken Sie auf "Vulnerabilität melden" um eine neue Sicherheitsanmerkung zu erstellen
Fügen Sie den genauen Dateipfad und Zeilennummer(n) ein, an dem die Vulnerabilität existiert
Bereitstellen Sie detaillierte Schritte zur Wiederherstellung des Problems und erklären Sie den Sicherheitsimpact

Außerhalb des Geltungsbereichs

Berichte ohne genaue code Zeilenbezug in GitHub
Berichte, die nicht über GitHub Sicherheitsanmerkung eingereicht wurden
Theoretische Vulnerabilitäten ohne Nachweis eines Proof of Concept
Fehler in drittigen Plattformen, Abhängigkeiten oder Diensten, die Capgo direkt nicht beheben kann (melden Sie diese beispielsweise an Supabase).
Soziale Ingenieurskunst oder Phishingversuche
Angriffe auf die Verfügbarkeit
SSRF- oder DNS-Spoofing-Berichte gegen Webhooks oder Website-Vorschau. Diese Funktionen laufen auf serverlosen Infrastruktur und können nicht verwendet werden, um private Capgo-Infrastruktur zu erreichen, daher sind sie in unserem Umfeld nicht ausnutzbar.
Benutzer-eigene Anwendung code oder Projekt-Konfiguration, die Capgo nicht besitzt, versendet, oder kontrolliert, einschließlich Dateien wie capacitor.config.ts, config.capacitor.ts, Quellcode code und Umgebungsabhängige Einstellungen.
Zugriff auf Capgo-Bundle-Dateien oder Beweis dafür, dass die Bundle-Dateien heruntergeladen werden können. Bundle-Dateien sind öffentliche Web-Ressourcen, die Benutzer darüber informiert werden und der Zugriff darauf wird nicht als Datenverletzung betrachtet.

Supabase und Drittanbieterdienste

Wenn die Ursache ein Bug oder eine Ausfallstelle der Supabase-Plattform oder eines Dienstes ist, melden Sie dies bei Supabase und nicht bei Capgo. Wenn die anfällige Logik, SQL, RPC, RLS-Politik, Edge-Funktion oder Konfiguration von Capgo erstellt oder gewählt wurde und wir sie in unserem Projekt beheben können, ist sie im Umfang, auch wenn Supabase den Endpunkt bereitstellt. Für Befunde über das Verhalten von Supabase selbst sollten Sie einen reproduzierbaren Fall und die genaue Supabase-Einstellung oder Konfigurationsänderung angeben, die es in einem Projekt wie unserem verhindert.

Beispiele

Nicht gültig hier

Ein Bug, Ausfall oder Verhalten der Supabase-Plattform, das nur Supabase beheben kann
Ein Befund, den Sie nicht reproduzieren können
Eine Behauptung, die Capgo für das Verhalten von Supabase verantwortlich macht, ohne einen Capgo-kontrollierten Fix oder die genaue Supabase-Einstellung/Konfigurationsänderung zu zeigen

Gültig hier

Eine von Capgo kontrollierte Supabase-Misconfiguration, die wir in unseren Projekt-Einstellungen beheben können (mit Schritten)
Ein von Capgo besitzener SQL, RPC, RLS, Funktion oder Integrationsproblem, das unsicherer Supabase-Verwendung führt
Auswertbarer Fehler in Capgo's Supabase-Projekt, -Schema oder -Policies, auch wenn er über einen Supabase-Endpunkt ausgelöst wird

Bekannte Einschränkungen der Supabase-Auth-Funktion (bereits gemeldet)

Einige Ergebnisse werden wiederholt gemeldet und werden durch Supabase-Auth-Standardeinstellungen oder Plattformverhalten verursacht und nicht durch Capgo code. Wir überprüfen diese nur, wenn sie in einem geteilten Supabase-Demo-Projekt wie unserem reproduzierbar sind und wenn die Korrektur eine Änderung der Supabase-Seite ist, die keine Änderung der Capgo-Sicherheitsregeln erfordert. Wenn die Korrektur eine Änderung der Capgo-besitzenen SQL, RPCs, RLS-Policies, Funktionen oder Anwendungslogik erfordert, melden Sie es uns, da dies im Geltungsbereich ist.

Stellen Sie einen auswertbaren Fall zusammen und identifizieren Sie die genaue Korrektur: entweder die Supabase-Einstellung/ -Konfigurationsänderung, die ein Supabase-Verhaltensproblem löst, oder die Capgo-besitzene code-/Konfigurationsobjekt, das geändert werden muss.
Das E-Mail-Verifizierungsverhalten ist so zu erwarten, dass es den Einstellungen Ihres Supabase-Auth-Projekts folgt (z.B. ob die E-Mail-Bestätigung deaktiviert und die capture-basierte Auth verwendet wird).
Die Passwortsynchronisierungs- und -wiederherstellungsflüsse erfordern nicht immer die Wiederholung des alten Passworts oder die erneute Verifizierung, wenn Supabase-Auth so konfiguriert ist.
Wenn das Problem in dieser Liste steht, aber Sie können in dem bereitgestellten Projekt oder in einem konkreten Capgo-besitzenen Sicherheitsfehler eine konkrete Supabase-Seitenerfassung vorzeigen, können wir es in den Geltungsbereich aufnehmen.

Für Fragen zu unserem Bug Bounty-Programm wenden Sie sich bitte über unsere GitHub-Sicherheitsberichte.