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 Schwachstellen in unserem Codebase zu helfen.

Offene Quellcode 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 einschließlich Backend-Diensten und Landing-Website

Repository ansehen Sicherheitslücke melden

Capacitor-Updater-Plugin

Das Kern-Capacitor-Plugin, das über die Luft über mobile Geräte aktualisiert

Repository ansehen Sicherheitslücke melden

Anforderungen für gültige Berichte

Um für das Bug Bounty-Programm in Frage zu kommen, 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 liefern, um das Problem zu demonstrieren

Wichtig: Wenn Sie die genaue Zeile von __CAPGO_KEEP_0__ in __CAPGO_KEEP_1__ nicht bereitstellen können, an der das Problem besteht, wird Ihr Bericht nicht für das Bug Bounty Programm zugelassen. Berichte müssen ausschließlich über __CAPGO_KEEP_2__ 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. 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.

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 nicht nach Status-Updates wie "haben Sie das überprüft?" oder ähnliche Fragen. Sobald wir bestätigen, dass wir Ihren Bericht erhalten haben, reicht das. Danach ist noch viel Arbeit zu leisten, und die Erstellung eines Pull-Requests kann mehrere Tage dauern.
  • Wichtig:

__CAPGO_KEEP_2__ Capgo ist eine kleine, selbstfinanzierte Firma, daher sind unsere Bounties niedriger als bei großen Unternehmen. Berichte ohne einen klaren Ausführungsweg werden bis zu 30 $ ausgezahlt. Ausführungen mit realen, reproduzierbaren Auswirkungen auf Capgo werden bis zu 300 $ ausgezahlt. Zahlungen werden nur nachdem wir das Problem identifiziert haben, es behoben haben, einen Pull-Request erstellt haben und Sie nach der Veröffentlichung bestätigt haben, dass die Reparatur funktioniert, ausgezahlt. 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

  1. Navigieren Sie zum relevanten Repository auf GitHub
  2. Klicken Sie auf die "Sicherheit"-Schaltfläche
  3. Klicken Sie auf "Vulnerabilität melden" 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 den Sicherheitsausfall

Außerhalb des Rahmens

  • Berichte ohne genaue code Zeilenreferenzen in GitHub
  • Berichte, die nicht über GitHub Security Advisory eingereicht wurden
  • Theoretische Vulnerabilitäten ohne Nachweis eines Proof of Concept
  • Fehler in dritter Partei-Plattformen, Abhängigkeiten oder Diensten, die Capgo direkt nicht beheben kann (melden Sie diese upstream, zum Beispiel an Supabase)
  • Soziale Ingenieurskunst- oder Phishingversuche
  • Dienstverweigerungsangriffe
  • 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.

Supabase und Drittanbieterdienste

Wenn die Ursache ein Bug oder ein Problem bei Supabase ist, melden Sie es an Supabase, 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 Informationen ü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 von Supabase, das nur Supabase beheben kann
  • Ein Fund, 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-Miskonfiguration, die wir in unseren Projekt-Einstellungen (mit Schritten) beheben können
  • Ein von Capgo-besitzenes SQL, RPC, RLS, Funktion oder Integrationsproblem, das eine unsichere Supabase-Nutzung verursacht
  • Ein wiederholbarer Fehler in Capgo's Supabase-Projekt, -Schema oder -Policies, selbst wenn er über einen Supabase-Endpunkt ausgelöst wird

Bekannte Supabase-Auth-Begrenzungen (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 gemeinsamen Supabase-Demo-Projekt wie unserem reproduzierbar sind und wenn der Fix eine Supabase-Seiteneinstellung/ -Konfigurationsänderung ist, die keine Änderung der Capgo-Sicherheitsregeln erfordert. Wenn der Fix eine Änderung von Capgo-besitzten SQL, RPCs, RLS-Policies, -Funktionen oder -Anwendungslogik erfordert, melden Sie es uns, da dies im Umfang ist.

  • Bereitstellen Sie einen wiederholbaren Fall und identifizieren Sie den genauen Fix: entweder die Supabase-Einstellung/Konfigurationsänderung, die ein Supabase-Verhaltensproblem löst, oder das von Capgo-besitzene code/Konfigurationsobjekt, das geändert werden muss.
  • Die E-Mail-Verifizierungsverhalten ist so zu erwarten, dass es Ihren Supabase-Auth-Projekt-Einstellungen 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 Wiederholung der Verifizierung, wenn Supabase-Auth so konfiguriert ist.
  • Wenn das Problem in dieser Liste ist, aber Sie können in dem bereitgestellten Projekt oder in einem konkreten Capgo-besitzenen Sicherheitsfehler einen konkreten Supabase-Seitigen Fix zeigen, können wir es in den Umfang aufnehmen.

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