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 Quellen Code

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

GitHub Organisation: github.com/Cap-go

Capgo Backend & Landing

Haupt Capgo-Repository, das Backend-Dienste und die Landing-Website enthält

Repository ansehen Sicherheitsproblem melden

Capacitor Updater-Plugin

Das Kern- Capacitor-Plugin, das drahtlose Updates auf mobilen Geräten verwaltet

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:

  • You müssen die genaue Datei und Zeilennummer in unserem GitHub-Repository angeben, an der die Schwachstelle besteht
  • Sie müssen Ihr Bericht über GitHub Security Advisory im relevanten Repository einreichen
  • 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: Wenn Sie nicht die genaue Zeile von code in GitHub angeben können, an der das Problem besteht, ist Ihr Bericht nicht für das Bug Bounty-Programm qualifiziert. Berichte müssen über GitHub Security Advisory eingereicht werden. Die Zahlungen werden über Algora.io abgewickelt; bitte erstellen Sie dort ein Konto, 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 zusammenarbeiten, die unsere Zeit nicht respektieren. Bitte halten Sie die Kommunikation ruhig und folgen Sie diesem Programm.

  • Wir beantworten Sicherheitsberichte und -brüche innerhalb von 24-72 Stunden.
  • 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 als Spam gelten.
  • Nur Berichte, die diesem Bug Bounty-Programm folgen, werden akzeptiert; alles andere kann blockiert werden.
  • Bitten Sie uns nicht nach Statusaktualisierungen wie "haben Sie schon überprüft?" oder ähnliche Fragen. Sobald wir bestätigen, dass wir Ihr Bericht erhalten haben, reicht das. Danach bleibt noch viel Arbeit zu leisten, 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 $ 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 Bounties 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. Zahlungen werden nur nachdem wir das Problem identifiziert, es behoben, einen Pull-Request erstellt und Sie nach der Veröffentlichung bestätigt haben, dass die Reparatur funktioniert, ausgezahlt.

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 "Ein Sicherheitslücke melden" um einen neuen Sicherheitsbericht zu erstellen
  4. Inkludieren Sie den genauen Dateipfad und Zeilennummer(n), an dem die Sicherheitslücke existiert
  5. Bereitstellen Sie detaillierte Schritte, um das Problem nachzubilden und erklären Sie die Sicherheitsauswirkungen

Außerhalb des Geltungsbereichs

  • Berichte ohne genaue code-Zeilenreferenzen in GitHub
  • Berichte, die nicht über GitHub Sicherheitsberatung eingereicht werden
  • Theoretische Sicherheitslücken ohne Beweis eines Proof-of-Concept
  • Schwachstellen in Dritt-Plattformen, Abhängigkeiten oder Diensten, die Capgo direkt nicht beheben kann (melden Sie diese upstream, zum Beispiel an Supabase).
  • Versuche der sozialen Manipulation oder Phishing
  • Angriffe auf die Verfügbarkeit
  • Berichte über SSRF oder DNS-Spoofing gegen Webhooks oder Website-Vorschau. Diese Funktionen laufen auf serverlosen Infrastruktur 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 Beweis, 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.

Supabase und Dritt-Dienste

Wenn der ursprüngliche Grund ein Bug in der Supabase-Plattform oder einem Dienst ist, melden Sie ihn an Supabase und nicht an 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, selbst wenn Supabase den Endpunkt bereitstellt. Für Funde über das Verhalten von Supabase selbst einschließlich eines reproduzierbaren Falls und der genauen Supabase-Einstellung oder Konfigurationsänderung, die es in einem Projekt wie unserem verhindert.

Beispiele

Kein gültiger Fall hier

  • A Plattformfehler von Supabase, der nur von Supabase behoben werden kann
  • Eine nicht reproduzierbare Entdeckung
  • Eine Behauptung, die Supabase-Verhalten ohne Anzeige einer durch Capgo kontrollierten Fixung oder der genauen Supabase-Einstellung/ Konfigurationsänderung Capgo verantwortet

Gültig hier

  • Eine durch Capgo kontrollierte Supabase-Misconfiguration, die wir in unseren Projekt-Einstellungen (mit Schritten) beheben können
  • Eine durch Capgo besitzene SQL, RPC, RLS, Funktion oder Integrationsproblematik, die eine unsichere Supabase-Nutzung verursacht
  • Eine reproduzierbare Problematik in Capgo's Supabase-Projekt, Schema oder Richtlinien, auch wenn sie über einen Supabase-Endpunkt ausgelöst wird

Bekannte Supabase-Auth-Begrenzungen (Bereits gemeldet)

Einige Entdeckungen werden wiederholt gemeldet und werden durch Supabase-Auth-Standardeinstellungen oder Plattformverhalten und nicht durch Capgo code verursacht. Wir prüfen diese nur, wenn sie in einem geteilten Supabase-Demo-Projekt wie unserem reproduziert werden können und wenn der Fix eine Supabase-Seiteneinstellungskonfigurationsänderung ist, die nicht die Capgo-Sicherheitsregeln ändert. Wenn der Fix eine Änderung der durch Capgo besitzenen SQL, RPCs, RLS-Richtlinien, Funktionen oder Anwendungslogik erfordert, melden Sie es uns, da dies im Geltungsbereich ist.

  • Stellen Sie einen reproduzierbaren Fall vor und identifizieren Sie den genauen Fix: entweder die Supabase-Einstellung/Konfigurationsänderung, die ein Supabase-Verhaltensproblem behebt, oder das durch Capgo besitzene code/Konfigurationsobjekt, das geändert werden muss.
  • Die E-Mail-Verifizierungsverhalten ist erwartungsgemäß an die Einstellungen Ihres Supabase-Auth-Projekts angepasst (z.B. ob E-Mail-Bestätigung deaktiviert und Capture-basierte Auth verwendet wird).
  • Passwort-Update- und -Konto-Wiederherstellungsflüsse erfordern möglicherweise nicht immer die Wiederholung oder Wiederherstellung des alten Passworts, wenn Supabase Auth so konfiguriert ist.
  • Wenn das Problem in dieser Liste aufgeführt ist, aber Sie können ein konkretes Supabase-Seitenvorschlag in dem bereitgestellten Projekt oder ein konkretes Capgo-besitzenes Sicherheitsdefekt anbieten, können wir es in den Geltungsbereich aufnehmen.

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