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

GitHub Organisation: github.com/Cap-go

Anforderungen für gültige Meldungen

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

• You must identify the exact file and line number in our GitHub repository where the vulnerability exists
• Your report must be submitted through GitHub Security Advisory on the relevant repository
• Sie müssen eine klare Beschreibung der Schwachstelle und ihres potenziellen Auswirkungen liefern
• Sie müssen reproduzierbare Schritte liefern, um die Schwachstelle zu demonstrieren

Reaktionszeit und Respekt

Wir sind freundlich und zahlen für gültige Meldungen, aber wir können 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.
• Bitte spam uns nicht. Mehr als drei E-Mails an einem Tag gelten als Spam und werden blockiert.
• Wir zahlen keine Belohnungen für Berichte, die diese Regeln ignorieren oder als Spam gelten.
• Wir akzeptieren nur Berichte, die diesem Bug-Bounty-Programm entsprechen; alles andere kann blockiert werden.
• Bitte stellen Sie keine Anfragen zum Status wie "haben Sie das überprüft?" oder ähnliche Fragen. Sobald wir bestätigen, dass wir Ihren Bericht erhalten haben, ist das genug. Danach ist noch viel Arbeit zu leisten und die Erstellung eines Pull-Requests kann einige Tage dauern.

Wie man einen Bericht einreicht

1. Navigieren Sie zum relevanten Repository auf GitHub
2. Klicken Sie auf die "Sicherheit"-Registerkarte
3. Klicken Sie auf "Melden Sie eine Sicherheitslücke" und erstellen Sie ein neues Sicherheitsbericht
4. Bitten Sie um detaillierte Schritte, um das Problem nachzubilden, und erklären Sie den Sicherheitsimpact
5. Außerhalb des Rahmens

Berichte ohne genaue __CAPGO_KEEP_0__ Zeilenbezug in __CAPGO_KEEP_1__

• Reports without exact code line references in GitHub
• Reports not submitted through GitHub Security Advisory
• Bugs in drittigen Plattformen, Abhängigkeiten oder Diensten, die __CAPGO_KEEP_0__ direkt nicht beheben kann (melden Sie diese upstream, zum Beispiel an Supabase)
• Bugs in third-party platforms, dependencies, or services that Capgo cannot fix directly (report those upstream, for example to Supabase).
• Dienstleistungsunterbrechungen
• 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_KEEP_0__-Infrastruktur zu erreichen, daher sind sie in unserem Umfeld nicht ausnutzbar.
• SSRF or DNS spoofing reports against webhooks or website preview. These features run on serverless infrastructure and cannot be used to reach private Capgo infrastructure, so they are not exploitable in our environment.
• Benutzer-eigene Anwendung code oder Projekt-Konfiguration, die Capgo nicht besitzt, versendet, kontrolliert oder einschließt, einschließlich Dateien wie capacitor.config.ts, config.capacitor.ts, Anwendungskomponenten code und Umgebungsabhängige Einstellungen.
• Zugriff auf Capgo Paketdateien oder Beweis dafür, dass Paketdateien heruntergeladen werden können. Paketdateien sind öffentliche Web-Ressourcen, Benutzer werden darüber informiert und Zugriff darauf gilt nicht als Datenverletzung.

Supabase und Drittanbieterdienste

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

Beispiele

Bekannte Supabase Auth Einschränkungen (Bereits gemeldet)

Einige Funde 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 die Korrektur eine Supabase-Seiteneinstellung 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 reproduzierbaren Fall vor 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 erwartet, dass es Ihren Supabase Auth-Projekt-Einstellungen folgt (z. B. ob die E-Mail-Bestätigung deaktiviert ist und ob eine Capture-basierte Auth verwendet wird).
• Die Passwortsynchronisierung und die Wiederherstellungsflüsse erfordern möglicherweise nicht immer die Wiederholung des alten Passworts oder die erneute Verifizierung, 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 in den Geltungsbereich aufnehmen.

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