Sicherheitspolitik

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

Bei Capgo legen wir die Sicherheit unserer Systeme auf jeden Fall an erste Stelle. Dennoch können wir, trotz aller Anstrengungen im Bereich der System-Sicherheit, immer noch Schwachstellen vorfinden.

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 besseren Abschirmung unserer Kunden und unserer Systeme zu helfen.

Vulnerabilitäten außerhalb des Angriffsszenarios:

Clickjacking auf Seiten ohne sensitive Aktionen.
Unauthentifizierte Logout-/Login-CSRF-Angriffe.
Angriffe, die das Vorgehen eines Man-in-the-Middle-Angriffs oder physischen Zugriffs auf ein Gerät eines Benutzers erfordern.
Angriffe, die soziale Ingenieurskunst erfordern.
Jede Aktivität, die zu einer Störung unseres Dienstes (DoS) führen könnte.
Inhaltsmanipulation und Textinjektionsprobleme ohne Anzeige eines Angriffsszenarios/ohne die Möglichkeit, HTML/CSS zu modifizieren.
E-Mail-Betrug
Fehlende DNSSEC, CAA, CSP-Kopfzeilen
Mangelnde Sicherheit oder HTTP-only-Flag bei nicht-sensiblen Cookies
Totale Links
Benutzer-Enumeration
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.
Benutzer-eigene Anwendung code oder Projekt-Konfiguration, die Capgo nicht besitzt, versendet, oder kontrolliert, einschließlich Dateien wie capacitor.config.ts, config.capacitor.ts, Anwendungskomponenten 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, Benutzer werden darüber informiert und 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-Seitenausfall behandelt, wenn sie in einem gemeinsam genutzten Supabase-Demo-Projekt, konfiguriert wie unseres, reproduzierbar sind und wenn eine Änderung der Supabase-Konfiguration 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 ein Capgo-Problem und sollte an uns gemeldet werden.

Berichte müssen eine reproduzierbare Demo-Supabase-Projekt enthalten, mit Schritten, das unsere Einstellungen und das Verhalten demonstriert.
Die Berichte müssen den genauen Fix-Pfad enthalten: entweder die Supabase-Einstellung/ Konfigurationsänderung, die das Verhalten löst, oder das Capgo-besitzene code-/Konfigurationsobjekt, 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 die 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-Seitenaufbau mit keiner Capgo-Policy-Änderung zeigt oder einen konkreten Capgo-besitzenen Defekt zeigt, werden wir es als handlungsfähig betrachten.

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önnen 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önnen zwischen feindlichem Erkundungsverhalten und weißer Huthforschung 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!
Vorteile aus der Entdeckung der Schwachstelle oder des Problems nicht nutzen, z. B. indem Sie mehr Daten als notwendig herunterladen, um die Schwachstelle zu demonstrieren, oder indem Sie oder andere Daten löschen oder ändern.

Berichterstattungsleitlinien:

Senden Sie Ihre Ergebnisse über unser GitHub-Sicherheitsbericht:: https://github.com/Cap-go/capgo/security/advisories/new
Bitte stellen Sie sicher, dass Sie genügend Informationen bereitstellen, 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 niemanden andern mitteilen, bis wir es erforscht, behoben und unsere 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 Informationen nicht enthalten sein sollten:
- Informationen über Capgo-Kundenprojekte
- Capgo-Kunden-Daten
- Informationen über Capgo-Mitarbeiter, -Auftragnehmer oder -Partner

Was wir versprechen:

Wir werden Ihnen innerhalb von 7 Geschäftsstagen mit unserer Bewertung des Berichts und einer erwarteten Lösungsdate antworten.
Wenn Sie die Anweisungen oben befolgt haben, werden wir Ihnen keine rechtlichen Schritte gegenüberstehen, was den Bericht betrifft.
We behandeln Ihre Meldung mit strenger Vertraulichkeit und geben Ihre persönlichen Daten ohne Ihre Zustimmung an Dritte weiter.
Wir werden Sie über den Fortschritt bei der Behebung des Problems informieren.
In der öffentlichen Information über das gemeldete Problem geben wir Ihren Namen als Entdecker des Problems an (sofern Sie dies nicht anders wünschen).
Wenn gelöschte Daten in den an uns geteilten Protokollen auftauchen, behandeln wir sie als Debugging-Information zur Behebung des Problems, 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 über das Problem leisten, nachdem es gelöst ist.