Sicherheitspolitik

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 aufgrund höchster Priorität. Dennoch können, trotz unseres Einsatzes für die Sicherheit der Systeme, noch immer Schwachstellen vorhanden sein.

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

Vulnerabilitäten außerhalb des Rahmens:

Klickjacking auf Seiten ohne sensitive Aktionen.
Unauthentifizierte Logout-/Login-CSRF-Angriffe.
Angriffe, die ein Man-in-the-Middle- oder physisches Zugriff auf ein Gerät eines Benutzers erfordern.
Angriffe, die soziale Ingenieurskunst erfordern.
Jeder Aktivität, die zu einer Störung unserer Dienstleistung (DoS) führen könnte.
Inhaltsmanipulation und Textinjektion ohne Anzeige eines Angriffsszenarios/ohne die Möglichkeit, HTML/CSS zu ändern.
E-Mail-Manipulation
Fehlende DNSSEC-, CAA- und CSP-Kopfzeilen
Fehlende Sicherheit oder HTTP-only-Flag bei nicht-sensiblen Cookies
Tote Links
Benutzerzuordnung
SSRF- oder DNS-Manipulationen bei Webhooks oder Website-Vorschauen. 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.
Benutzerbesitzene Anwendung code oder Projekt-Konfiguration, die Capgo nicht besitzt, versendet, kontrolliert oder schickt, einschließlich Dateien wie capacitor.config.ts, config.capacitor.ts, Anwendungskomponenten code und Umgebungsabhängige Einstellungen.
Zugriff auf Capgo-Bundle-Dateien oder Beweis, dass Bundle-Dateien heruntergeladen werden können. Bundle-Dateien sind öffentliche Web-Assets, die Nutzer darüber informiert werden, und der Zugriff darauf wird nicht als Datenverletzung betrachtet.

Bekannte Supabase-Auth-Begrenzungen

Einige Funde werden wiederholt gemeldet und mit Supabase-Auth-Verhalten in Verbindung gebracht. Diese werden nur als Supabase-Seitenaufgaben behandelt, wenn sie in einem gemeinsam genutzten Supabase-Demo-Projekt wie unserem konfiguriert werden können und wenn eine Supabase-Konfigurationsänderung das Verhalten ohne Änderung der Capgo-Sicherheitsregeln behebt. Wenn die Reparatur eine Änderung der Capgo-besitzenen SQL, RPCs, RLS-Politiken, Funktionen oder Anwendungslogik erfordert, handelt es sich um eine Capgo-Aufgabe und sollte an uns gemeldet werden.

Reports müssen eine wiederholbare Demo-Supabase-Projekt enthalten, mit Schritten, die unsere Einstellungen widerspiegeln und das Verhalten demonstrieren.
Reports müssen den genauen Fix-Pfad enthalten: entweder die Supabase-Einstellung/Config-Änderung, die das Verhalten löst, oder das Capgo-besitzene code/config-Objekt, das geändert werden muss.
Konto-/E-Mail-Flüsse werden gegen die Supabase-Projekt-Einstellungen validiert (z. B. ob die E-Mail-Verifizierung deaktiviert ist und der Capture-Flow verwendet wird).
Passwörter- 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-Policy-Änderung beweist oder ein konkretes Capgo-besitzenes Defekt zeigt, wird es als handlungsfähig bewertet.

Testleitlinien:

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önnten die Dienste stören, Schwachstellen ausnutzen, zu Systeminstabilitäten oder Sicherheitsverletzungen führen und gegen die Nutzungsbedingungen unserer upstream-Anbieter verstoßen. Unsere eigenen Sicherheitssysteme könnten feindliche Erkundungen nicht von weißen-Hut-Forschungen unterscheiden. Wenn Sie einen automatischen Scanner ausführen möchten, benachrichtigen Sie uns bei security@capgo.app und führen ihn nur auf Ihrem eigenen Capgo-Projekt aus. Projekte von anderen Kunden NICHT angreifen.
Nutzen Sie die Schwachstelle oder das Problem nicht aus, indem Sie zum Beispiel mehr Daten als notwendig herunterladen, um die Schwachstelle zu demonstrieren, oder indem Sie oder indem Sie andere Personen Daten löschen oder ändern.

Berichterstattungsleitlinien:

Melden Sie Ihre Erkenntnisse über unsere GitHub Sicherheitsanzeige:: https://github.com/Cap-go/capgo/sicherheit/anzeigen/neu
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.

Offenlegungsleitlinien:

Um unsere Kunden zu schützen, sollten Sie die Schwachstelle nicht anderen Personen offenbaren, bis wir sie 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:
- Daten zu Kundenprojekten von Capgo
- Capgo-Kunden-Daten
- Informationen über Capgo-Mitarbeiter, -Auftragnehmer oder -Partner

What wir versprechen:

Wir werden Ihre Meldung innerhalb von 7 Geschäfts-Tagen beantworten und unsere Bewertung der Meldung sowie einen erwarteten Lösungszeitpunkt mitteilen.
Wenn Sie die oben genannten Anweisungen befolgt haben, werden wir Ihnen keine rechtlichen Schritte gegenübertreten, was die Meldung betrifft.
Wir werden Ihre Meldung mit strenger 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 zum Problem, das Sie gemeldet haben, werden wir Ihren Namen als Entdecker des Problems nennen (sofern Sie dies nicht anders wünschen).
Wenn sich gelöschte Daten in den mit uns geteilten Protokollen befinden, behandeln wir sie als Debugging-Informationen, die zur Behebung des Problems verwendet werden, nie als Grund für Rache oder Vergeltung.

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