Sicherheitspolitik

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

Bei Capgo legen wir die Sicherheit unserer Systeme auf höchsten Wert an. 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 Systeme zu helfen.

Vulnerabilitäten außerhalb des Geltungsbereichs:

Klicken Sie auf Seiten ohne sensitive Aktionen auf die Oberfläche.
Unauthentifizierte/Abmelde-/Anmelde-CSRF.
Angriffe, die ein Man-in-the-Middle- oder physisches Zugriff auf ein Gerät eines Benutzers erfordern.
Angriffe, die soziale Ingenieurskunst erfordern.
Jede Aktivität, die zu einer Störung 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 Sicherheits- oder HTTP-only-Flag bei nicht-sensiblen Cookies
Tote Links
Benutzerzuordnung
SSRF- oder DNS-Betrugsmeldungen gegen Webhooks oder Website-Vorschau. Diese Funktionen laufen auf serverlosen Infrastrukturen und können nicht verwendet werden, um private Capgo-Infrastruktur zu erreichen, daher sind sie in unserem Umfeld nicht ausnutzbar.
Benutzerbesitzene Anwendungs-code oder Projekt-Konfiguration, die Capgo nicht besitzt, versendet, kontrolliert oder schickt, einschließlich Dateien wie capacitor.config.ts, config.capacitor.ts, Anwendungs-Quellcode code und Umgebungsabhängige Einstellungen.
Zugriff auf Capgo-Bundle-Dateien oder Beweis 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-Seitenausfall behandelt, wenn sie in einem gemeinsam mit uns konfigurierten Supabase-Demo-Projekt 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 eine Capgo-Auseinandersetzung 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 validiert (z.B. ob die E-Mail-Verifizierung deaktiviert ist und der Capture-Flow verwendet wird).
Passworts- und E-Mail/Passworts-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 einen konkreten Capgo-besitzenen Fehler zeigt, werden wir es als handlungsfähig betrachten.

Testleitlinien:

Laufen Sie keine automatischen Scanner auf anderen Kundenprojekten aus. Die Ausführung von automatischen Scannern kann die Kosten für unsere Benutzer erhöhen. Aggressiv konfigurierte Scanner könnten die Dienste stören, Ausfälle ausnutzen, Systeminstabilitäten oder Sicherheitsverletzungen verursachen und gegen die Nutzungsbedingungen unserer Auftragsverarbeiter verstoßen. Unsere eigenen Sicherheitssysteme können zwischen feindlichem Erkundungsverhalten und weißer Huthaftforschung nicht unterscheiden. Wenn Sie einen automatischen Scanner ausführen möchten, informieren Sie uns bitte bei security@capgo.app und führen Sie ihn nur auf Ihrem eigenen Capgo-Projekt aus. Attackieren Sie nicht die Projekte anderer Kunden!
Benutzen 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 ändern Sie andere Personen Daten.

Berichterstattungsleitlinien:

Melden 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.

Offenlegungsleitlinien:

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 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 Capgo-Kundenprojekten
- Capgo-Kunden-Daten
- Capgo-Mitarbeiter-, -Auftragnehmer- oder -Partner-Daten

Worauf wir uns verpflichten:

Wir werden Ihre Meldung innerhalb von 7 Geschäftstagen beantworten und Ihnen unsere Bewertung der Meldung sowie einen erwarteten Fertigstellungstermin mitteilen.
Wenn Sie unsere Anweisungen befolgt haben, werden wir Ihnen keine rechtlichen Schritte gegenübertreten.
Wir behandeln Ihre Meldung mit strenger Vertraulichkeit und übermitteln Ihre persönlichen Daten ohne Ihre Zustimmung nicht an Dritte weiter.
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 nicht anders wünschen).
Wenn bei den von uns erhaltenen Logfiles gelöschte Daten auftauchen, behandeln wir sie als Debugging-Informationen zur Behebung des Problems 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 des Problems leisten.