Sicherheitspolitik

Kontakt: https://github.com/Cap-go/capgo/security/advisories/new
Kanonische Adresse: 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, immer noch Schwachstellen vorhanden sein.

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

Schwachstellen außerhalb des Geltungsbereichs:

Klickjacking auf Seiten ohne sensitive Aktionen.
Unauthentifizierte/Abmelde-/Anmelde-CSRF.
Angriffe, die eine Man-in-the-Middle- oder physische Zugriff auf ein Gerät eines Benutzers erfordern.
Angriffe, die soziale Ingenieurskunst erfordern.
Jeder Aktivität, die zu einer Unterbrechung unserer Dienstleistung (DoS) führen könnte.
Angriffe auf Inhalte und Textinjektion ohne Anzeige eines Angriffsszenarios/ohne die Möglichkeit, HTML/CSS zu modifizieren.
E-Mail-Betrug
Fehlende DNSSEC-, CAA- und CSP-Kopfzeilen
Fehlende Sicherheits- oder HTTP-only-Flag bei nicht-sensiblen Cookies
Tote Links
Benutzerzuordnung
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.
User-owned application code or project configuration that Capgo does not own, ship, or control, including files such as capacitor.config.ts, config.capacitor.ts, app source code, and environment-specific settings.
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 Auth Limitationen

Einige Funde werden wiederholt gemeldet und mit Supabase Auth-Verhalten verbunden. Diese werden nur als Supabase-Seitige Probleme behandelt, wenn sie in einem geteilten Supabase-Demo-Projekt wie unserem reproduziert werden können und wenn eine Supabase-Konfigurationsänderung das Verhalten ohne Änderung der Capgo-Sicherheitsregeln behebt. Wenn die Behebung 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 wiederholbare Demo- Supabase-Projekt enthalten, mit Schritten, das unsere Einstellungen und das Verhalten demonstriert.
Berichte müssen den genauen Fix-Pfad enthalten: entweder die Supabase-Einstellung/ Konfigurationsänderung, die das Verhalten löst, oder das Capgo-besitzene code-/Konfig-Objekt, 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.
Passwort- und E-Mail/Passwort-Update-Flüsse können von der aktuellen Supabase-Auth-Sitzung und den Wiederherstellungs-Einstellungen abhängen.
Wenn ein Demo-Projekt einen konkreten Supabase-Seitenaufbau mit keiner Capgo-Politikänderung oder einen konkreten Capgo-besitzenen Defekt zeigt, werden wir es als handlungsfähig betrachten.

Testleitlinien:

Bitte führen Sie keine automatischen Scanner auf anderen Kundenprojekten aus. Die Durchführung von automatischen Scannern kann für unsere Benutzer Kosten verursachen. Aggressiv konfigurierte Scanner könnten die Dienste stören, Ausnutzungen von Schwachstellen ausnutzen, zu Systeminstabilitäten oder Sicherheitsverletzungen führen und gegen die Nutzungsbedingungen unserer Auftragsverarbeiter verstoßen. Unsere eigenen Sicherheitssysteme können zwischen feindlichem Erkundungsverhalten und weißer Hutforschung nicht unterscheiden. Wenn Sie einen automatischen Scanner ausführen möchten, teilen Sie uns dies bitte mit an security@capgo.app und führen Sie ihn nur auf Ihrem eigenen Capgo-Projekt aus. Attackieren Sie Projekte von anderen Kunden NICHT.
Verwenden Sie die Schwachstelle oder das Problem nicht aus, indem Sie zum Beispiel mehr Daten als erforderlich herunterladen, um die Schwachstelle zu demonstrieren, oder indem Sie oder indem Sie andere Personen Daten löschen oder ändern.

Berichterstattungsleitfaden:

Senden Sie Ihre Ergebnisse über unser GitHub Sicherheitsbericht:: https://github.com/Cap-go/capgo/security/advisories/new
Bieten Sie ausreichend Informationen an, um das Problem nachzubilden, 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 geprüft, aber unbezahlt.

Offenlegungsleitfaden:

Um unsere Kunden zu schützen, sollten Sie das Problem nicht anderen Personen offenbaren, bis wir es erforscht, abgeklärt und unseren betroffenen Kunden informiert haben.
Wenn Sie Ihre Forschung über Capgo an einer Konferenz, in einem Blog oder in 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 über Capgo-Kundenprojekte
- Capgo-Kunden-Daten
- Informationen über Capgo-Mitarbeiter, -Auftragnehmer oder -Partner

Worauf wir uns verpflichten:

Wir werden Ihre Meldung innerhalb von 7 Werktagen beantworten und Ihnen unsere Bewertung sowie eine erwartete Lösungsdate zukommen lassen.
Wenn Sie unsere Anweisungen befolgt haben, werden wir Ihnen keine rechtlichen Schritte gegenübertreten.
Wir behandeln Ihre Meldung streng vertraulich und geben Ihre persönlichen Daten ohne Ihre Zustimmung nicht an Dritte weiter.
Wir halten Sie über den Fortschritt bei der Lösung des Problems auf dem Laufenden.
In der öffentlichen Information über das Problem, das Sie gemeldet haben, werden wir Ihren Namen als Entdecker des Problems nennen (sofern Sie nicht anders wünschen).
Wenn bei den von uns erhaltenen Logfiles sensible Daten 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 möchten nach der Lösung des Problems einen aktiven Beitrag zur Veröffentlichung des Problems leisten.