Zum Hauptinhalt springen

Sicherheitsrichtlinie

Kontakt: https://github.com/Cap-go/capgo.app/security/advisories/new
Canonical-URL: https://capgo.app/security/
Security.txt: https://capgo.app/.well-known/security.txt (/security.txt)

Bei Capgo hat die Sicherheit unserer Systeme höchste Priorität. Doch egal wie viel Aufwand wir in die Systemsicherheit stecken, es können dennoch Schwachstellen existieren.

Wenn du eine Schwachstelle entdeckst, lass es uns bitte wissen, damit wir so schnell wie möglich Maßnahmen ergreifen können. Hilf uns dabei, unsere Kunden und Systeme besser zu schützen.

Schwachstellen außerhalb des Scopes:

  • Clickjacking auf Seiten ohne sensible Aktionen.
  • Unauthentifizierte/Logout/Login CSRF.
  • Angriffe, die MITM oder physischen Zugriff auf das Gerät eines Nutzers erfordern.
  • Angriffe, die Social Engineering erfordern.
  • Jegliche Aktivitäten, die zu einer Dienstunterbrechung (DoS) führen könnten.
  • Content-Spoofing und Text-Injection-Probleme ohne Angriffsvektor oder die Möglichkeit, HTML/CSS zu manipulieren.
  • E-Mail-Spoofing
  • Fehlende DNSSEC-, CAA- oder CSP-Header
  • Fehlende Secure- oder HttpOnly-Flags bei nicht-sensiblen Cookies
  • Tote Links
  • User-Enumeration
  • SSRF- oder DNS-Spoofing-Meldungen zu Webhooks oder Website-Previews. Diese Features laufen auf Serverless-Infrastruktur und können nicht genutzt werden, um private Capgo Infrastruktur zu erreichen; in unserer Umgebung sind sie daher nicht ausnutzbar.
  • Vom Nutzer verwaltete code App- oder Projektkonfiguration, die Capgo nicht besitzt, ausliefert oder kontrolliert, einschließlich Dateien wie capacitor.config.ts, config.capacitor.ts, App-Source code und umgebungsspezifischen Einstellungen.
  • Zugriff auf Capgo Bundle-Dateien oder der Nachweis, dass Bundle-Dateien heruntergeladen werden können. Bundle-Dateien sind öffentliche Web-Assets, Nutzer werden darüber informiert, und der Zugriff darauf gilt nicht als Datenleck.
  • Nicht authentifizierte Capgo Plugin/API Endpoints, die absichtlich öffentlich sind – einschließlich channel_self set und Update/Stats-Endpoints, die keinen API Key erfordern – sind keine Schwachstellen. Bitte nicht als solche melden.
  • Wenn Uploader oder UI die Verschlüsselung für Bundles, die über external_url ausgeliefert werden, falsch kennzeichnen, ist das keine Capgo Schwachstelle (die Verschlüsselung extern gehosteter Bundles liegt außerhalb der Kontrolle von Capgo).

Bekannte Einschränkungen von Supabase Auth

Einige Befunde werden wiederholt gemeldet und hängen mit dem Verhalten von Supabase Auth zusammen. Sie werden nur dann als Probleme auf Supabase-Seite behandelt, wenn sie in einem gemeinsam genutzten Supabase-Demo-Projekt, das wie unseres konfiguriert ist, reproduzierbar sind und eine Änderung der Supabase-Konfiguration das Verhalten behebt, ohne die Capgo-Sicherheitsregeln zu ändern. Erfordert die Behebung Änderungen an SQL, RPCs, RLS-Policies, Funktionen oder App-Logik, die Capgo gehören, ist das ein Capgo-Problem und sollte uns gemeldet werden.

  • Meldungen müssen ein reproduzierbares Supabase-Demo-Projekt mit Schritten enthalten, das unseren Einstellungen entspricht und das Verhalten zeigt.
  • Meldungen müssen den genauen Lösungsweg enthalten: entweder die Supabase-Einstellungs-/Konfigurationsänderung, die das Verhalten behebt, oder das code/config-Objekt, das Capgo gehört und geändert werden muss.
  • Account-/E-Mail-Flows werden anhand der Supabase-Projekteinstellungen validiert (z. B. ob die E-Mail-Verifizierung deaktiviert ist und ein Capture-Flow genutzt wird).
  • Passwort- und E-Mail/Passwort-Update-Flows können von der aktuellen Supabase Auth Session und den Re-Verification-Einstellungen abhängen.
  • Wenn ein Demo-Projekt eine konkrete Behebung auf Supabase-Seite ohne Änderung der Capgo-Policy nachweist oder einen konkreten Defekt in Capgo zeigt, prüfen wir das als umsetzbar.

Testing-Richtlinien:

  • Führe keine automatisierten Scanner auf Projekten anderer Kunden aus. Automatisierte Scans können Kosten für unsere Nutzer verursachen. Aggressiv konfigurierte Scanner könnten unbeabsichtigt Dienste stören, Schwachstellen ausnutzen, zu Systeminstabilität oder Sicherheitsverletzungen führen und gegen die Nutzungsbedingungen unserer Upstream-Provider verstoßen. Unsere Sicherheitssysteme können feindliche Reconnaissance nicht von Whitehat-Research unterscheiden. Wenn du einen automatisierten Scanner nutzen möchtest, informiere uns unter security@capgo.app und führe ihn nur auf deinem eigenen Capgo Projekt aus. Greife NICHT Projekte anderer Kunden an.
  • Nutze die entdeckte Schwachstelle oder das Problem nicht aus – zum Beispiel, indem du mehr Daten herunterlädst als zur Demonstration der Schwachstelle nötig ist, oder indem du Daten anderer Personen löschst oder veränderst.

Richtlinien für Meldungen:

  • Reiche deine Ergebnisse über unser GitHub Security Advisory ein: https://github.com/Cap-go/capgo.app/security/advisories/new
  • Bitte liefere ausreichend Informationen, um das Problem zu reproduzieren, damit wir es so schnell wie möglich beheben können.
  • Wir nehmen Sicherheitsberichte für Capgo Plugins an und prüfen diese. Bezahlte Bounties für Plugin code sind jedoch auf @capgo/capacitor-updater. begrenzt. Andere Capgo Plugins sind kostenlos und nicht Teil unseres kostenpflichtigen Produktangebots; Berichte dazu werden geprüft, aber nicht vergütet.

Richtlinien zur Offenlegung:

  • Um unsere Kunden zu schützen, veröffentliche das Problem bitte erst, nachdem wir es untersucht, behoben und die betroffenen Kunden informiert haben.
  • Wenn Sie Ihre Forschung zu Capgo auf einer Konferenz, in einem Blog oder einem anderen öffentlichen Forum öffentlich teilen möchten, senden Sie uns bitte mindestens 30 Tage vor der Veröffentlichung einen Entwurf zur Prüfung und Freigabe zu. Bitte beachten Sie, dass Folgendes nicht enthalten sein darf:
    • Daten zu Kundenprojekten von Capgo
    • Daten der Kunden von Capgo
    • Informationen über Mitarbeiter, Auftragnehmer oder Partner von Capgo

Unser Versprechen:

  • Wir werden innerhalb von 7 Werktagen auf Ihren Bericht reagieren und Ihnen unsere Bewertung sowie ein voraussichtliches Datum für die Behebung mitteilen.
  • Sofern Sie die oben genannten Anweisungen befolgt haben, werden wir keine rechtlichen Schritte gegen Sie im Zusammenhang mit dem Bericht einleiten.
  • Wir behandeln Ihren Bericht streng vertraulich und geben Ihre persönlichen Daten ohne Ihre Erlaubnis nicht an Dritte weiter.
  • Wir halten Sie über die Fortschritte bei der Problemlösung auf dem Laufenden.
  • In öffentlichen Informationen zum gemeldeten Problem nennen wir Ihren Namen als Entdecker (sofern Sie nichts anderes wünschen).
  • Wenn in Logs, die Sie mit uns teilen, geleakte Daten auftauchen, behandeln wir sie als Debugging-Informationen zur Fehlerbehebung – niemals als Grund für Vergeltungsmaßnahmen.

Wir bemühen uns, alle Probleme so schnell wie möglich zu lösen, und möchten bei der abschließenden Veröffentlichung des Problems nach der Lösung eine aktive Rolle spielen.