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

GitHub Organisation: github.com/Cap-go

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 bereitstellen, um das Problem zu demonstrieren

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.
• Stören 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 angenommen; alles andere kann blockiert werden.
• Stellen Sie keine Anfragen 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.

Wie man einen Bericht erstellt

1. Navigieren Sie zum relevanten Repository auf GitHub
2. Klicken Sie auf die "Sicherheit"-Schaltfläche
3. Klicken Sie auf "Vulnerabilität melden" um einen neuen Sicherheitsbericht 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 nachzustellen und erklären Sie die Sicherheitsauswirkungen

Außerhalb des Geltungsbereichs

• Berichte ohne genaue code-Zeilenreferenzen in GitHub
• Berichte, die nicht über GitHub-Sicherheitsbericht eingereicht wurden
• Theoretische Vulnerabilitäten ohne Beweis eines Proof of Concept
• Fehler in dritter Ebene, Abhängigkeiten oder Diensten, die Capgo direkt nicht beheben kann (melden Sie diese upstream, zum Beispiel an Supabase)
• Soziale Ingenieurskunst- oder Phishingversuche
• Angriffe auf die Verfügbarkeit von Diensten
• SSRF- oder DNS-Spoofing-Berichte gegen Webhooks oder Website-Vorschau. Diese Funktionen laufen auf serverlosen Infrastrukturen und können nicht verwendet werden, um private Capgo-Infrastruktur zu erreichen, daher sind sie in unserem Umfeld nicht ausnutzbar.
• Benutzer-eigene Anwendungs-code oder Projekt-Konfiguration, die Capgo nicht besitzt, versendet, kontrolliert oder einschließt, einschließlich Dateien wie capacitor.config.ts, config.capacitor.ts, Anwendungs-code-Quellcode und Umgebungsabhängige Einstellungen.
• Zugriff auf Capgo-Bundle-Dateien oder Beweise dafür, dass Bundle-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 Drittanbieterdienste

Wenn die Ursache ein Bug oder eine Supabase-Plattform oder -Dienststörung ist, melden Sie dies 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 Befunde über Supabase-Verhaltensweisen selbst sollten Sie einen reproduzierbaren Fall und die genaue Supabase-Einstellung oder Konfigurationsänderung angeben, die es in einem wie unser Projekt verhindert.

Beispiele

Bekannte Supabase-Auth-Begrenzungen (Bereits gemeldet)

Einige Erkenntnisse werden wiederholt gemeldet und werden durch Supabase-Auth-Standardeinstellungen oder Plattformverhalten und nicht durch Capgo code verursacht. Wir überprüfen diese nur, wenn sie in einem geteilten Supabase-Demo-Projekt konfiguriert wie unseres reproduzierbar sind und wenn der Fix eine Supabase-Seiteneinstellung/ Konfigurationsänderung ist, die keine Änderung der Capgo-Sicherheitsregeln erfordert. Wenn der Fix eine Änderung der Capgo-geführten SQL-, RPCs-, RLS-Richtlinien, Funktionen oder App-Logik erfordert, melden Sie es uns, da dies im Geltungsbereich ist

• Bereitstellen Sie einen reproduzierbaren Fall und identifizieren Sie die genaue Lösung: entweder die Supabase-Einstellung/Konfigurationsänderung, die ein Supabase-Verhaltensproblem behebt, oder das von Capgo gehaltene code/Konfigurationsobjekt, das geändert werden muss
• Die E-Mail-Verifizierungsverhalten ist so zu erwarten, dass es den Einstellungen Ihres Supabase-Auth-Projekts folgt (z. B. ob die E-Mail-Bestätigung deaktiviert ist und ob die Capture-basierte Auth verwendet wird)
• Die Passwortsynchronisierungs- und Konto-Wiederherstellungs-Flü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 aufgeführt ist, aber Sie können eine konkrete Supabase-Seitenaufgabe in dem bereitgestellten Projekt oder eine konkrete Capgo-besitzene 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.