Zum Hauptinhalt springen
Capgo Logo

Bug-Bounty-Programm

Capgo ist sich der Sicherheit und Transparenz verpflichtet. 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

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

GitHub Organisation: github.com/Cap-go

Capgo Backend & Landung

Capgo Backend und Produktrepository (capgo.app API, Dashboard und zugehörige Dienste)

Ablage des Repositories Meldung einer Sicherheitslücke

Capacitor-Updater-Plugin

Der Kern-Capacitor-Plugin, der sich um die Übertragung von Updates auf mobilen Geräten kümmert

Aufrufen des Repositoriums Meldung einer Sicherheitslücke

Anforderungen für gültige Meldungen

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

  • Sie müssen die genaue Datei und Zeilennummer in unserem GitHub-Repository identifizieren, an der die Sicherheitslücke besteht
  • Ihre Meldung muss über GitHub Security Advisory auf dem relevanten Repository eingereicht werden
  • Sie müssen eine klare Beschreibung der Sicherheitslücke und ihres potenziellen Auswirkungen bereitstellen
  • Sie müssen reproduzierbare Schritte bereitstellen, um das Problem zu demonstrieren

Wichtig: Wenn Sie die genaue Zeile von code in GitHub nicht bereitstellen können, an der das Problem besteht, wird Ihr Bericht nicht für das Bug Bounty-Programm in Frage kommen. Berichte müssen ausschließlich über GitHub Security Advisory eingereicht werden. Zahlungen werden über Algora.io gehandhabt; bitte erstellen Sie dort ein Konto, damit wir Ihnen direkt auf der Plattform zahlen können.

Wartezeit und Respekt

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

  • Wir reagieren auf Sicherheitsberichte und -verletzungen innerhalb von 24-72 Stunden.
  • Spammen Sie uns nicht. Mehr als drei E-Mails an einem Tag gelten als Spam und werden blockiert.
  • Wir zahlen nicht für Berichte, die diese Regeln ignorieren oder als Spam gelten.
  • Wir nehmen nur Berichte an, die diesem Bug Bounty-Programm folgen; alles andere kann blockiert werden.
  • Stellen Sie keine Anfragen für 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 zu tun, und die Erstellung eines Pull-Requests kann mehrere Tage dauern.

Wichtig: Capgo ist ein kleines, selbstfinanziertes Unternehmen, daher sind unsere Bountys geringer als bei großen Unternehmen. Berichte ohne klaren Ausführungsweg werden bis zu 30 Euro bezahlt. Ausführungen mit realen, reproduzierbaren Auswirkungen auf Capgo werden bis zu 300 Euro 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 nachdem wir das Problem identifiziert haben, den Fix freigegeben haben und Sie nach der Veröffentlichung bestätigt haben, dass der Fix für Sie funktioniert. Die Eröffnung oder das Linken eines Pull-Requests reicht nicht aus, um eine Zahlung zu erhalten. Dieser Prozess dauert in der Regel einige Tage bis einige Wochen, abhängig von Schweregrad und Release-Rhythmus. Bitte senden Sie keine Nachrichten wie "um bezahlt zu werden"; Zahlungen erfolgen nur, wenn der Release live ist und Sie den Fix getestet und validiert haben.

Wie man einen Bericht einreicht

  1. Navigieren Sie zum relevanten Repository auf GitHub
  2. Klicken Sie auf die "Sicherheit"-Schaltfläche
  3. Klicken Sie auf „Melden Sie eine Sicherheitslücke“ um eine neue Sicherheitsanzeige zu erstellen
  4. Inkludieren Sie den genauen Dateipfad und Zeilennummer(n), an dem die Vulnerabilität existiert
  5. Bereitstellen Sie detaillierte Schritte, um das Problem nachzubilden und erklären Sie die Sicherheitsauswirkungen

Außerhalb des Rahmens

  • Berichte ohne genaue code-Zeilenreferenzen in GitHub
  • Berichte, die nicht über GitHub-Sicherheitsbericht erstellt wurden
  • Theoretische Vulnerabilitäten ohne Beweis eines Proof of Concept
  • Fehler in Dritt-Partei-Plattformen, Abhängigkeiten oder Diensten, die Capgo nicht direkt beheben kann (melden Sie diese upstream, zum Beispiel an Supabase).
  • Versuche der sozialen Manipulation oder Phishing
  • 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.
  • User-owned application code or project configuration that Capgo does not own, ship, or control, including files such as capacitor.config.ts, config.capacitor.ts, app source code, and environment-specific settings.
  • Zugriff auf Capgo-Bundle-Dateien oder Beweise dafür, dass diese Dateien heruntergeladen werden können. Bundle-Dateien sind öffentliche Web-Assets, die Benutzer darüber informiert werden und der Zugriff darauf wird nicht als Datenverletzung betrachtet.
  • Unauthentifizierte Capgo-Plugin- oder API-Endpunkte, die absichtlich öffentlich sind — einschließlich channel_self set und update/stats-Endpunkte, die kein API-Schlüssel erfordern — sind keine Schwachstellen. Melden Sie sie nicht als solche.
  • Uploader oder UI, die die Verschlüsselung für Bundle, die über external_url bereitgestellt werden, falsch kennzeichnen, ist keine Capgo-Schwachstelle (die Verschlüsselung extern gehosteter Bundle liegt außerhalb der Kontrolle von Capgo).

Supabase und Dritt-Partei-Dienste

Wenn die Ursache ein Fehler im Supabase-Plattform oder -Dienst ist, melden Sie ihn bei Supabase und nicht 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 auch dann im Geltungsbereich, wenn Supabase den Endpunkt bereitstellt. Für Erkenntnisse über das Supabase-Verhalten selbst müssen Sie einen reproduzierbaren Fall und die genaue Supabase-Einstellung oder Konfigurationsänderung angeben, die es in einem Projekt verhindert, das wie unseres konfiguriert ist.

Beispiele

Nicht gültig hier

  • Ein Fehler im Supabase-Plattform, eine Ausfallzeit oder ein Verhalten, das nur Supabase beheben kann
  • Ein nicht reproduzierbares Problem
  • Eine Behauptung, die Supabase-Verhalten ohne Anzeige eines von Capgo kontrollierten Behebungs- oder der genauen Supabase-Einstellung/Konfigurationsänderung Capgo für verantwortlich macht

Gültig hier

  • Ein von Capgo kontrolliertes Supabase-Misconfigurations, das wir in unseren Projekt-Einstellungen (mit Schritten) beheben können
  • Ein von Capgo-besitzener SQL, RPC, RLS, Funktion oder Integrationsproblem, das zu unsicherem Supabase-Verhalten führt
  • Ein reproduzierbares Problem in Capgo's Supabase-Projekt, Schema oder Richtlinien, auch wenn es über einen Supabase-Endpunkt ausgelöst wird

Bekannte Supabase-Auth-Begrenzungen (bereits gemeldet)

Einige Funde werden wiederholt gemeldet und werden durch Supabase-Auth-Standardwerte oder Plattformverhalten verursacht und nicht durch Capgo code. Wir überprüfen diese nur, wenn sie in einem geteilten Supabase-Demo-Projekt wie unserem reproduziert werden können und wenn der Fix ein Supabase-Seitig-Konfigurationsänderung ist, die keine Änderung der Capgo Sicherheitsregeln erfordert. Wenn der Fix eine Änderung der Capgo-besitzenen SQL, RPCs, RLS-Politiken, Funktionen oder Anwendungslogik erfordert, melden Sie es uns, da dies im Umfang ist.

  • Bieten Sie einen reproduzierbaren Fall und identifizieren Sie den genauen Fix: entweder die Supabase-Einstellung/Konfigurationsänderung, die ein Supabase-Verhaltensproblem löst, oder die Capgo-besitzene code/Konfigurationsobjekt, das geändert werden muss.
  • Die E-Mail-Verifizierungsverhalten ist erwartet, dass es Ihren Supabase-Auth-Projekt-Einstellungen folgt (z. B. ob die E-Mail-Bestätigung deaktiviert ist und ob die Capture-basierte Auth verwendet wird).
  • Passwortsynchronisierung und -wiederherstellungsflüsse erfordern möglicherweise nicht immer die Wiederholung oder -überprüfung des alten Passworts, wenn Supabase Auth so konfiguriert ist.
  • Wenn das Problem in dieser Liste ist, aber Sie können einen konkreten Supabase-Seitigen Fix in dem bereitgestellten Projekt oder einen konkreten Capgo-besitzenen Sicherheitsfehler zeigen, können wir es im Umfang berücksichtigen.

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