Zum Hauptinhalt springen

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, auditten und zu ihnen beitragen.

GitHub Organisation: github.com/Cap-go

Capgo Backend & Landing

Capgo backend und Produkt-Repository (capgo.app API, Dashboard und zugehörige Dienste)

Repository ansehen Sicherheitslücke melden

Capacitor Updater-Plugin

Der Kern-Capacitor-Plugin, der drahtlose Updates auf mobilen Geräten verwaltet

Repository ansehen Sicherheitslücke melden

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 Schwachstelle existiert
  • Ihre Meldung muss über GitHub Sicherheitsanzeige auf dem relevanten Repository eingereicht werden
  • Sie müssen eine klare Beschreibung der Schwachstelle und ihres potenziellen Auswirkungen enthalten
  • 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 existiert, wird Ihre Meldung nicht für das Bug Bounty Programm qualifiziert. Meldungen müssen nur über GitHub Sicherheitsanzeige eingereicht werden. Zahlungen werden über Algora.io gehandhabt; bitte erstellen Sie ein Konto dort, damit wir Ihnen direkt auf der Plattform zahlen können.

Antwortzeit und Respekt

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

  • Wir antworten auf Sicherheitsberichte und -brüche innerhalb von 24-72 Stunden.
  • Bitte spammen Sie uns nicht. Mehr als drei E-Mails an einem Tag gilt als Spam und wird blockiert.
  • Wir zahlen nicht für Berichte, die diese Regeln ignorieren oder Spam sind.
  • Nur Berichte, die diesem Bug Bounty Programm folgen, werden akzeptiert; alles andere kann blockiert werden.
  • Bitte stellen Sie keine Anfragen für Status-Updates wie "haben Sie das überprüft?" oder ähnliche Fragen. Sobald wir bestätigen, dass wir Ihre Meldung erhalten haben, ist das genug. Danach gibt es 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 Bausoldatenbeträge niedriger als bei großen Unternehmen. Berichte ohne einen 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 Bausoldaten 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 überprüft, aber unbezahlt bleiben. Zahlungen werden nur dann ausgeführt, wenn wir das Problem identifiziert haben, den Fix freigegeben haben und Sie nach der Veröffentlichung bestätigt haben, dass der Fix funktioniert. Die Eröffnung oder das Verlinken eines Pull-Requests reicht nicht aus, um eine Zahlung zu erhalten. Dieser Prozess dauert in der Regel einige Tage bis einige Wochen, je nach 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. Fügen Sie den genauen Dateipfad und Zeilennummer(n) ein, 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 Nachweis eines Proof of Concept
  • Fehler in drittigen Plattformen, Abhängigkeiten oder Diensten, die Capgo nicht direkt beheben kann (melden Sie diese an den Anbieter, z.B. 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 Infrastrukturen und können nicht verwendet werden, um auf private Capgo-Infrastruktur zuzugreifen, 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 Nutzer 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.
  • Der Upload- oder die UI-Bezeichnung der Verschlüsselung für Bundle, die über external_url bereitgestellt werden, ist keine Capgo-Schwachstelle (die Verschlüsselung extern gehosteter Bundle liegt außerhalb der Capgo-Kontrolle).

Supabase und Dritt-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 im Geltungsbereich, auch wenn Supabase den Endpunkt bereitstellt. Für Befunde über Supabase-Verhaltensweisen 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 Fehler im Supabase-Plattform, eine Ausfallzeit oder ein Verhalten, das nur Supabase beheben kann
  • Ein Befund, den Sie nicht reproduzieren können
  • 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

  • Eine von Capgo kontrollierte Supabase-Miskonfiguration, die 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 reproduzierbarer Fehler in Capgo's Supabase-Projekt, Schema oder Richtlinien, auch wenn er ü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 gemeinsamen Supabase-Demo-Projekt wie unserem reproduziert werden können und wenn die Korrektur eine Supabase-seitige Konfigurationsänderung ist, die keine Änderung der Capgo Sicherheitsregeln erfordert. Wenn die Korrektur eine Änderung der Capgo-besitzenen SQL, RPCs, RLS-Politiken, Funktionen oder Anwendungslogik erfordert, melden Sie sie uns, da dies im Umfang liegt.

  • Bieten Sie einen reproduzierbaren Fall an und identifizieren Sie die genaue Korrektur: entweder die Supabase-Einstellung/Konfigurationsänderung, die ein Supabase-Verhaltensproblem behebt, oder die Capgo-besitzene code/Konfigurationsobjekt, das geändert werden muss.
  • Die E-Mail-Verifizierungsverhalten ist erwartungsgemäß an Ihre Supabase Auth-Projekt-Einstellungen (z. B. ob die E-Mail-Bestätigung deaktiviert ist und ob eine Capture-basierte Auth verwendet wird).
  • Passwortsynchronisierung und -wiederherstellung können in bestimmten Konfigurationen von Supabase Auth nicht immer die Eingabe oder Wiederherkunft des alten Passworts erfordern.
  • 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.