Datenschutzrichtlinie

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

Bei Capgo stellen wir die Sicherheit unserer Systeme auf höchsten Wert. Dennoch können, trotz aller Anstrengungen, noch immer Schwachstellen vorhanden sein.

Entdecken Sie eine Schwachstelle, so 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.

Aus dem Bereich der Schwachstellen fallen:

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 ändern.
E-Mail-Betrug
Fehlende DNSSEC-, CAA- und CSP-Kopfzeilen
Fehlende sichere oder nur über HTTP gesicherte Cookies
Tote Links
Benutzeridentifizierung
SSRF- oder DNS-Betrugsmeldungen 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-Begrenzungen

Einige Ergebnisse werden wiederholt gemeldet und mit Supabase Auth-Verhalten verbunden. Diese werden nur als Supabase-Seitenausgaben behandelt, wenn sie in einem gemeinsamen 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 die Änderung eine Änderung der Capgo-besitzenen SQL, RPCs, RLS-Politiken, Funktionen oder Anwendungslogik erfordert, handelt es sich um eine Capgo-Ausgabe und sollte an uns gemeldet werden.

Reports müssen eine wiederholbare Demo- Supabase-Projekt enthalten, mit Schritten, das unsere Einstellungen und das Verhalten demonstriert.
Reports 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 und der Capture-Flow verwendet wird) validiert.
Passwörter- und E-Mail/Passwörter-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 beweist oder einen konkreten Capgo-besitzenen Defekt zeigt, werden wir es als handhabbar betrachten.

Testleitlinien:

Laufen Sie keine automatischen Scanner auf anderen Kundenprojekten aus. Die Ausfü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 upstream-Anbieter verstoßen. Unsere eigenen Sicherheitssysteme können zwischen feindseligem Erkundungsverhalten und weißer Hutforschung nicht unterscheiden. Wenn Sie einen automatischen Scanner ausführen möchten, melden Sie sich bei security@capgo.app und führen Sie ihn nur auf Ihrem eigenen Capgo-Projekt aus. Attackieren Sie nicht die Projekte anderer Kunden!
Vermeiden Sie es, die Schwachstelle oder das Problem auszunutzen, indem Sie zum Beispiel mehr Daten herunterladen, als notwendig, um die Schwachstelle zu demonstrieren, oder indem Sie oder ändern Sie andere Leute Daten.

Richtlinien für Meldungen:

Senden Sie Ihre Ergebnisse über unser GitHub Sicherheitsbericht:: https://github.com/Cap-go/capgo/security/advisories/new
Bieten Sie bitte ausreichend Informationen an, um das Problem zu reproduzieren, damit wir es so schnell wie möglich lösen 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.

Richtlinien für Offenlegung:

Um unsere Kunden zu schützen, sollten Sie das Problem nicht anderen 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 zukommen lassen, um ihn zu überprüfen und zu genehmigen, mindestens 30 Tage vor der Veröffentlichungsdatum. 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 der Meldung sowie einen erwarteten Fertigstellungstermin mitteilen.
Wenn Sie die oben genannten Anweisungen befolgt haben, werden wir Ihnen keine rechtlichen Schritte gegenüberstehen.
Wir behandeln Ihre Meldung mit strenger Vertraulichkeit und übermitteln Ihre persönlichen Daten ohne Ihre Zustimmung an Dritte nicht weiter.
Wir halten Sie über den Fortschritt bei der Behebung des Problems auf dem Laufenden.
In der öffentlichen Information über das Problem, das Sie gemeldet haben, geben wir Ihren Namen als Entdecker des Problems an (sofern Sie dies nicht anders wünschen).
Wenn bei uns 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 möchten nach der Behebung des Problems einen aktiven Beitrag zur endgültigen Veröffentlichung über das Problem leisten.