Zum Hauptinhalt springen
Capgo-Logo

Sicherheitsrichtlinie

Kontakt: https://github.com/Cap-go/capgo/security/advisories/new
Kanonisches Dokument: https://capgo.app/security.txt

Bei Capgo legen wir die Sicherheit unserer Systeme auf jeden Fall an erste Stelle. Dennoch können, trotz aller Anstrengungen, noch immer Schwachstellen vorhanden sein.

Wenn Sie eine Schwachstelle entdecken, möchten wir davon wissen, damit wir schnellstmöglich Schritte unternehmen können, um sie zu beheben. Wir bitten Sie, uns bei der Verbesserung der Sicherheit unserer Kunden und unserer Systeme zu helfen.

Ausgeschlossene Schwachstellen:

  • Klickjacking auf Seiten ohne sensitive Aktionen.
  • Unauthentifizierte/Abmelde/Anmelde CSRF.
  • Angriffe, die einen Man-in-the-Middle-Angriff oder physischen Zugriff auf ein Gerät eines Benutzers erfordern.
  • Angriffe, die soziale Ingenieurskunst erfordern.
  • Jede Aktivität, die zu einer Unterbrechung unseres Dienstes führen könnte (DoS).
  • Inhaltsfälschung und Textinjektionsprobleme ohne Anzeige eines Angriffsszenarios/ohne die Möglichkeit, HTML/CSS zu ändern.
  • E-Mail-Fälschung
  • Fehlende DNSSEC, CAA, CSP-Kopfzeilen
  • Mangel an Secure oder HTTP-only-Flag auf nicht-sensitive Cookies
  • Tote Links
  • Benutzerzählung
  • SSRF- oder DNS-Spoofing-Berichte 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.
  • 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, Quellcode code und Umgebungsabhängige Einstellungen.
  • Zugriff auf Capgo-Bundle-Dateien oder Beweis dafür, dass die Bundle-Dateien heruntergeladen werden können. Bundle-Dateien sind öffentliche Web-Ressourcen, die Benutzer darüber informiert werden und der Zugriff darauf gilt nicht als Datenverletzung.

Bekannte Supabase Auth Einschränkungen

Einige Ergebnisse werden wiederholt gemeldet und mit dem Supabase Auth-Verhalten verbunden. Diese werden nur als Supabase-Seitenausgaben behandelt, wenn sie in einem geteilten Supabase-Demo-Projekt, das wie unseres konfiguriert ist, reproduziert werden können und wenn eine Supabase-Konfigurationsänderung das Verhalten ohne Änderung der Capgo-Sicherheitsregeln behebt. Wenn der Fix eine Änderung der Capgo-besitzenen SQL, RPCs, RLS-Politiken, Funktionen oder Anwendungslogik erfordert, handelt es sich um ein Capgo-Problem und sollte an uns gemeldet werden.

  • Berichte müssen eine reproduzierbare Demo-Supabase-Projekt enthalten, mit Schritten, das unsere Einstellungen und das Verhalten demonstriert.
  • Berichte müssen den genauen Fix-Weg enthalten: entweder die Supabase-Einstellung/Konfigurationsänderung, die das Verhalten behebt, oder das Capgo-besitzene code/Konfigurationsobjekt, das geändert werden muss.
  • Konto/E-Mail-Flüsse werden gegen die Supabase-Projekt-Einstellungen (z.B. ob die E-Mail-Verifizierung deaktiviert ist und der Capture-Flow verwendet wird) validiert.
  • Passworts- und E-Mail/Passworts-Update-Flüsse können von der aktuellen Supabase-Auth-Sitzung und den Wiederholungs-Einstellungen abhängen.
  • Wenn ein Demo-Projekt eine konkrete Supabase-Seitenaufgabe mit keiner Capgo-Änderung der Richtlinie oder eine konkrete Capgo-besitzene Defekt zeigt, überprüfen wir es als handlungsfähig.

Testrichtlinien:

  • Automatisierte Scanner auf anderen Kundenprojekten nicht ausführen. Die Ausführung von automatisierten Scannern kann für unsere Benutzer Kosten verursachen. Aggressiv konfigurierte Scanner können Dienste stören, Ausfälle ausnutzen, Systeminstabilität oder Sicherheitsverstöße verursachen und die Nutzungsbedingungen unserer Auftragsverarbeiter verletzen. Unsere eigenen Sicherheitssysteme können nicht zwischen feindlichem Erkundungsverhalten und weißer Hutforschung unterscheiden. Wenn Sie einen automatischen Scanner ausführen möchten, informieren Sie uns bitte bei security@capgo.app und führen ihn nur auf Ihrem eigenen Capgo-Projekt aus. Projekte anderer Kunden nicht angreifen!
  • Von der Entdeckung eines Problems oder einer Schwachstelle nicht profitieren, z.B. indem Sie mehr Daten als notwendig herunterladen, um die Schwachstelle zu demonstrieren, oder indem Sie oder andere Daten löschen oder ändern.

Berichterstattungsrichtlinien:

  • Senden Sie Ihre Erkenntnisse über unser GitHub Sicherheitsbericht:: https://github.com/Cap-go/capgo/security/advisories/new
  • Bieten Sie ausreichend Informationen an, um das Problem zu reproduzieren, damit wir es so schnell wie möglich beheben können.
  • 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 überprüft, aber unbezahlt.

Offenlegungsrichtlinien:

  • In Ordnung unsere Kunden zu schützen, sollten Sie das Problem nicht anderen offenbaren, bis wir es erforscht, angegangen und unsere betroffenen Kunden informiert haben.
  • Wenn Sie Ihre Forschungsergebnisse über Capgo an einer Konferenz, in einem Blog oder einem anderen öffentlichen Forum öffentlich teilen möchten, sollten Sie uns einen Entwurf mindestens 30 Tage vor der Veröffentlichungsdatum zukommen lassen, damit wir ihn überprüfen und genehmigen können. Bitte beachten Sie, dass folgende nicht enthalten sein sollten:
    • Informationen zu Kundenprojekten von Capgo
    • Daten von Capgo-Kunden
    • Informationen über Capgo-Mitarbeiter, -Auftragnehmer oder -Partner

Was wir versprechen:

  • Wir werden innerhalb von 7 Geschäftstagen auf Ihre Meldung reagieren und Ihnen unsere Bewertung der Meldung sowie einen erwarteten Lösungszeitpunkt mitteilen.
  • Wenn Sie unsere Anweisungen befolgt haben, werden wir keine rechtlichen Schritte gegen Sie in Bezug auf die Meldung einleiten.
  • Wir werden Ihre Meldung mit strengster Vertraulichkeit behandeln und Ihre persönlichen Daten ohne Ihre Zustimmung nicht an Dritte weitergeben.
  • Wir werden Sie über den Fortschritt bei der Behebung des Problems informieren.
  • In der öffentlichen Information über das gemeldete Problem werden wir Ihren Namen als Entdecker des Problems nennen (sofern Sie dies nicht anders wünschen).
  • Wenn gelöschte Daten in den mit uns geteilten Protokollen auftauchen, behandeln wir sie als Debugging-Informationen, um das Problem zu beheben, und nicht als Grund für Rache oder Vergeltung.

Wir streben danach, alle Probleme so schnell wie möglich zu lösen, und wir möchten einen aktiven Beitrag zur endgültigen Veröffentlichung des Problems leisten, nachdem es gelöst wurde.