Richtlinie zur Offenlegung von Schwachstellen
Zuletzt aktualisiert: 2024-12-19
1. Zweck der Richtlinie
Bei Whispie sind wir bestrebt, das höchste Sicherheitsniveau für unsere Nutzer aufrechtzuerhalten. Diese Richtlinie gibt Sicherheitsforschern Orientierung, wie sie in Whispie-Systemen und Drittanbieter-Integrationen (Stripe, Supabase, Facebook, Google Analytics, Twilio usw.) entdeckte Schwachstellen verantwortungsvoll offenlegen können.
Wir glauben, dass die Zusammenarbeit mit Sicherheitsforschern weltweit entscheidend für die Sicherheit unserer Nutzer ist. Wir ermutigen Sie, uns zu kontaktieren, um potenzielle Schwachstellen zu melden, die Sie entdecken.
2. Geltungsbereich
✅ Im Geltungsbereich befindliche Systeme
- whispieapp.com und alle Subdomains
- Whispie-Mobilanwendungen (iOS & Android)
- Alle API-Endpunkte und Dienste
- Drittanbieter-Integrationen und -Dienste:
- Stripe-Zahlungssysteme
- Supabase-Datenbank und -Authentifizierung
- Twilio-SMS-Verifizierung
- Facebook/Meta-Werbeintegrationen
- Google Analytics-Implementierung
- Cloudflare-Sicherheitsdienste
❌ Außerhalb des Geltungsbereichs
- Physische Sicherheitsbewertungen
- Social-Engineering-Angriffe
- DDoS-Angriffe oder volumetrische Tests
- Angriffe gegen Whispie-Mitarbeiter oder -Infrastruktur
- Drittanbieter-Dienste, die nicht direkt mit Whispie integriert sind
- Theoretische Schwachstellen ohne Proof-of-Concept
- Fehlende Sicherheitsheader ohne nachgewiesene Auswirkung
3. Regeln zur verantwortungsvollen Offenlegung
✅ Was zu tun ist
- Benachrichtigen Sie uns sofort nach Entdeckung einer potenziellen Schwachstelle
- Verwenden Sie die minimal notwendige Menge sensibler Daten, um die Schwachstelle zu demonstrieren
- Stellen Sie eine detaillierte Dokumentation Ihrer Erkenntnisse bereit
- Halten Sie die Kommunikation über die Schwachstelle vertraulich
- Geben Sie uns angemessene Zeit, die Schwachstelle zu beheben
- Testen Sie wenn möglich gegen Ihre eigenen Konten oder Testdaten
❌ Was nicht zu tun ist
- Daten löschen, ändern oder stehlen
- Tests durchführen, die zu Dienstunterbrechungen führen könnten
- Die Privatsphäre anderer Nutzer verletzen
- Social Engineering gegen Mitarbeiter oder Nutzer einsetzen
- Physische Angriffe gegen unsere Infrastruktur durchführen
- Schwachstellen öffentlich bekannt machen, bevor wir Zeit hatten, sie zu beheben
- Zahlung oder Vergütung für Schwachstellenberichte fordern
4. Sonderregeln für Drittanbieter-Integrationen
🔵 Facebook (Meta) Integration
- Missbrauch von Facebook-APIs oder Überschreitung von Ratenlimits vermeiden
- Nicht versuchen, ohne Autorisierung auf Nutzerdaten zuzugreifen
- Facebooks eigene Sicherheitsrichtlinien und Bug-Bounty-Programm befolgen
- Facebook-spezifische Schwachstellen gegebenenfalls an deren Sicherheitsteam melden
🟢 Google Analytics Integration
- Beim Testen von Analytics-Datenerhebungsmechanismen vorsichtig vorgehen
- Keine echten Nutzerdaten bei Tests verwenden
- Googles Nutzungsbedingungen einhalten
- Sich auf Whispies Implementierung konzentrieren, nicht auf Googles Infrastruktur
🟣 Stripe Integration
- Keine Tests mit echten Zahlungstransaktionen durchführen
- Nur Testkarten und Sandbox-Umgebungen verwenden
- Stripes Sicherheitsrichtlinien und Offenlegungsrichtlinien befolgen
- Stripe-spezifische Schwachstellen an deren Sicherheitsteam melden
🟠 Supabase Integration
- Datenbanksicherheit testen, ohne auf echte Nutzerdaten zuzugreifen
- Wenn möglich Testkonten und -datenbanken verwenden
- Supabase-Sicherheitsrichtlinien befolgen
- Sich auf Whispies Implementierung von Supabase-Diensten konzentrieren
5. Offenlegungsverfahren
1
Erstmeldung
Senden Sie Ihre Erkenntnisse per E-Mail an
[email protected] mit detaillierten Informationen, einschließlich:
- Beschreibung der Schwachstelle
- Schritte zur Reproduktion
- Potenzielle Auswirkungen
- Vorgeschlagene Korrekturen (falls vorhanden)
2
Verifizierung
Unser Sicherheitsteam bestätigt den Eingang innerhalb von 24–48 Stunden und verifiziert die Schwachstelle innerhalb von 3 Werktagen.
3
Behebung
Wir entwickeln eine Lösung für die Schwachstelle basierend auf deren Schweregrad und Komplexität.
4
Benachrichtigung
Wir halten Sie über unsere Fortschritte auf dem Laufenden und informieren Sie, wenn die Schwachstelle behoben wurde.
5
Öffentliche Bekanntmachung
Nach dem Deployment der Lösung können wir Ihren Beitrag öffentlich anerkennen (mit Ihrer Erlaubnis).
6. Reaktionszeitpläne
- Erstreaktion: 24–48 Stunden
- Schwachstellenverifizierung: 3 Werktage
- Behebungsentwicklung: Variiert je nach Schweregrad und Komplexität
- Öffentliche Bekanntmachung: 30 Tage nach Behebung
Hinweis: Komplexe Schwachstellen können für eine ordnungsgemäße Behebung zusätzliche Zeit erfordern.
8. Rechtlicher Schutz
Wir werden keine rechtlichen Schritte gegen Sie einleiten, wenn Sie Sicherheitsforschung gemäß dieser Richtlinie durchführen. Wir betrachten Aktivitäten, die mit dieser Richtlinie übereinstimmen, als „autorisiertes" Verhalten gemäß dem Computer Fraud and Abuse Act.
Wenn Ihre Aktivitäten jedoch nicht von dieser Richtlinie abgedeckte Handlungen umfassen, behalten wir uns das Recht vor, alle angemessenen Maßnahmen zu ergreifen, einschließlich rechtlicher Schritte.
9. Anerkennungsprogramm
Obwohl wir derzeit kein formelles Bug-Bounty-Programm betreiben, glauben wir daran, die wertvollen Beiträge von Sicherheitsforschern anzuerkennen. Mit Ihrer Erlaubnis können wir:
- Ihren Namen in unsere Security Hall of Fame aufnehmen
- Ihren Beitrag öffentlich anerkennen
- Ein Anerkennungsschreiben für Ihr berufliches Portfolio ausstellen
Wir evaluieren kontinuierlich unsere Sicherheitsanerkennungsprogramme und könnten in Zukunft monetäre Belohnungen einführen.
10. Richtlinienaktualisierungen
Wir können diese Richtlinie von Zeit zu Zeit aktualisieren. Das Datum „Zuletzt aktualisiert" oben auf dieser Seite gibt an, wann die letzten Änderungen vorgenommen wurden. Wir empfehlen Ihnen, diese Richtlinie regelmäßig zu überprüfen.