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.
  • CSRF bei unauthentifiziertem Logout/Login.
  • 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ühren Sie keine automatisierten Scanner auf Projekten anderer Kunden aus. Automatisierte Scanner können die Kosten für unsere Nutzer in die Höhe treiben. Aggressiv konfigurierte Scanner können versehentlich Dienste stören, Schwachstellen ausnutzen, zu Systeminstabilität oder Sicherheitsverletzungen führen und die Nutzungsbedingungen unserer Upstream-Anbieter verletzen. Unsere eigenen Sicherheitssysteme können feindliche Aufklärung nicht von Whitehat-Forschung unterscheiden. Wenn Sie einen automatisierten Scanner ausführen möchten, benachrichtigen Sie uns unter security@capgo.app und führen Sie ihn nur auf Ihrem eigenen Capgo-Projekt aus. Greifen Sie NICHT Projekte anderer Kunden an.
  • Nutzen Sie die entdeckte Schwachstelle oder das Problem nicht aus, indem Sie beispielsweise mehr Daten herunterladen, als zur Demonstration der Schwachstelle erforderlich ist, oder Daten anderer Personen löschen oder ändern.

Meldungsrichtlinien:

  • Reichen Sie Ihre Erkenntnisse über unser GitHub Security Advisory ein:: https://github.com/Cap-go/capgo.app/security/advisories/new
  • Bereiten Sie ausreichende Informationen zur Reproduktion des Problems vor, damit wir es so schnell wie möglich beheben können.
  • Wir akzeptieren und prüfen Sicherheitsberichte für Capgo-Plugins, aber bezahlte Bounties für Plugin-code sind auf @capgo/capacitor-updater. begrenzt. Andere Capgo-Plugins sind kostenlos nutzbar und sind nicht Teil unseres kostenpflichtigen Produktangebots, daher werden Berichte zu ihnen geprüft, aber nicht vergütet.

Richtlinien für die Offenlegung:

  • Um unsere Kunden zu schützen, geben Sie das Problem nicht an Dritte weiter, bis wir es untersucht, behoben und unsere 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.