Sicherheitspolitik

Kontakt: https://github.com/Cap-go/capgo/sicherheit/ratgeber/neu
Kanonische URL: https://capgo.app/sicherheit.txt

Bei Capgo stellen wir die Sicherheit unserer Systeme auf höchstem Niveau an. Dennoch können, trotz aller Anstrengungen im Bereich der System-Sicherheit, 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 anzugehen. Wir bitten Sie, uns bei der besseren Abschirmung unserer Kunden und unserer Systeme zu helfen.

Aus dem Rahmen fallende Schwachstellen:

Klickjacking auf Seiten ohne sensitive Aktionen.
Unauthentifizierte Logout-Login CSRF.
Angriffe, die einen Man-in-the-Middle-Angriff oder physischen 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.
Inhaltsheber und Textinjektionsprobleme ohne Anzeige eines Angriffsszenarios/ohne die Möglichkeit, HTML/CSS zu modifizieren.
E-Mail-Heber.
Fehlende DNSSEC-, CAA- und CSP-Kopfzeilen.
Fehlende Sicherheit oder HTTP-only-Flag auf nicht-sensiblen Cookies.
Tote Links.
Benutzerzuordnung.
SSRF- oder DNS-Heberberichte 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.
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 Einschränkungen.

Einige Befunde 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 konfiguriert wie unseres reproduziert werden können und wenn eine Supabase-Konfigurationsänderung das Verhalten ohne Änderung der Capgo-Sicherheitsregeln behebt. Wenn die Reparatur eine Änderung Capgo-besitzener SQL, RPCs, RLS-Politiken, Funktionen oder Anwendunglogik erfordert, handelt es sich um ein Capgo-Problem und sollte an uns gemeldet werden.

Reports müssen eine wiederholbare Demo-Supabase-Projekt enthalten, mit Schritten, das unsere Einstellungen widerspiegelt und das Verhalten demonstriert.
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 (z.B. ob die E-Mail-Verifizierung deaktiviert ist und der Capture-Flow verwendet wird) validiert.
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-Seitenaufwand mit keiner Capgo-Änderung der Richtlinie nachweist 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 Kosten für unsere Benutzer erhöhen. Aggressiv konfigurierte Scanner können die Dienste stören, Schwachstellen ausnutzen, zu Systeminstabilitäten oder Sicherheitsverletzungen führen und die Nutzungsbedingungen unserer Auftragslieferanten verletzen. Unsere eigenen Sicherheitssysteme können zwischen feindlichem Erkundungsverhalten und weißer Huthaftforschung nicht 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 anderer Kunden nicht angreifen.
Nutzen Sie die Schwachstelle oder das Problem nicht aus, indem Sie zum Beispiel mehr Daten herunterladen, als notwendig, um die Schwachstelle zu demonstrieren, oder indem Sie oder ändern Sie andere Leute Daten.

Berichterstattungsleitlinien:

Melden Sie Ihre Erkenntnisse über unseren GitHub Sicherheitsbericht:: https://github.com/Cap-go/capgo/sicherheit/advisories/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 überprüft, aber unbezahlt.

Offenlegungsleitlinien:

Um unsere Kunden zu schützen, sollten Sie das Problem nicht anderen Leuten 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 für die Überprüfung und Genehmigung mindestens 30 Tage vor der Veröffentlichungsdatum zukommen lassen. 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äftsstagen beantworten und unsere Bewertung der Meldung sowie einen erwarteten Lösungszeitpunkt mitteilen.
Wenn Sie die oben genannten Anweisungen befolgt haben, werden wir keine rechtlichen Schritte gegen Sie in Bezug auf die Meldung einleiten.
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 Lösung des Problems informieren.
In der öffentlichen Information zum Problem, das gemeldet wurde, 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.