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, auditieren und 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 das Problem zu demonstrieren

Antwortzeit 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 fragen Sie nicht nach Status-Updates wie "haben Sie das überprüft?" oder ähnliche Fragen. Sobald wir bestätigen, dass wir Ihren Bericht erhalten haben, ist das genug. Danach gibt es noch viel Arbeit zu tun, und die Erstellung eines Pull-Requests kann einige Tage dauern.

Wie man einen Bericht einreicht

1. Navigieren Sie zu dem 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. Bitten Sie um detaillierte Schritte, um das Problem nachzuvollziehen, und erklären Sie den Sicherheitsauswirkungen
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 Dritt-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).
• Dienstunterbrechungsangriffe
• 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_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.
• Eine vom Benutzer besitzene Anwendung code oder Projektkonfiguration, die Capgo nicht besitzt, versendet, kontrolliert oder einschließt, einschließlich Dateien wie capacitor.config.ts, config.capacitor.ts, Quellcode code und Umgebungsabhängige Einstellungen.
• Zugriff auf Capgo Paketdateien oder Beweis dafür, dass Paketdateien heruntergeladen werden können. Paketdateien sind öffentliche Web-Assets, die Benutzer darüber informiert werden und der Zugriff darauf gilt nicht als Datenverletzung.

Supabase und Drittanbieterdienste

Wenn die Ursache ein Bug im Supabase-Plattform oder -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 auch dann im Umfang, wenn Supabase den Endpunkt bereitstellt. Für Funde über Supabase-Verhalten selbst müssen Sie einen reproduzierbaren Fall und die genaue Supabase-Einstellung oder Konfigurationsänderung angeben, 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-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 der Fix eine Supabase-Seiteneinstellung ist, die keine Änderung der Capgo-Sicherheitsregeln erfordert. Wenn der Fix eine Änderung der Capgo-besitzenen SQL, RPCs, RLS-Policies, Funktionen oder Anwendungslogik erfordert, melden Sie es uns, da dies im Umfang 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 die Capgo-besitzene code/Konfigurationsobjekt, das geändert werden muss.
• Die E-Mail-Verifizierungsverhalten ist erwartungsgemäß an die Einstellungen Ihres Supabase Auth-Projekts (z. B. ob die E-Mail-Bestätigung deaktiviert ist und ob eine Capture-basierte Auth verwendet wird) angepasst.
• Die Passwortsynchronisierung und die Wiederherstellungsflüsse erfordern möglicherweise nicht immer die Eingabe 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 im bereitgestellten Projekt oder einen konkreten Capgo-besitzenen Sicherheitsfehler vorzeigen, können wir es in den Umfang aufnehmen.

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