Bug Bounty-Richtlinie von Doist

Bitte lies unsere Richtlinie sorgfältig durch, da sie genau festlegt, für welche gemeldeten Sicherheitsprobleme wir eine Prämie aussetzen. Nur Berichte, die über unser Kontaktformular eingereicht werden, können für eine Prämie berücksichtigt werden. Du kannst das Kontaktformular über den Button am Ende dieser Seite aufrufen.

Unser Bug Bounty Programm hier bei Doist ist ein wichtiger Bestandteil unserer Sicherheitsmaßnahmen. Wenn du eine Sicherheitslücke gefunden hast, von der wir deiner Meinung nach wissen sollten, würden wir gerne mit dir zusammenarbeiten. Für deinen Einsatz hast du möglicherweise Anspruch auf eine Prämie.

Anspruchsbedingungen

  • Du musst die erste Person sein, die die entsprechende Sicherheitslücke meldet, um für eine Prämie infrage zu kommen.
  • Du musst bereit sein, zusätzliche Informationen bereitzustellen, die von unserem Team zur Rekonstruktion und Behebung der Schwachstelle benötigt werden.

Programmregeln

  • Folge den Richtlinien von HackerOne zur Offenlegung von Sicherheitslücken.
  • Lösche alle Testdaten oder Testkonten, die du im Rahmen der Recherche erstellt hast.
  • Unterlasse es, die End-User anzugreifen oder mit ihnen zu interagieren.
  • Schau nicht in gestohlene User-Daten, einschließlich Anmeldedaten.
  • Führe keine automatisierten Scans oder Tests einschließlich DoS-Angriffen durch.
  • Führe keine Social Engineering-Angriffe wie Phishing durch.
  • Führe keine physischen Tests durch, bei denen du Mitarbeitende von Doist oder ihre Geräte einbeziehst.
Die Nichteinhaltung dieser Regeln führt zum sofortigen Ausschluss.

Zulässige Ziele

Einreichen des Berichts

  • Erstelle einen detaillierten Bericht mit klar rekonstruierbaren Schritten, den Auswirkungen auf unsere Produkte und/oder unsere User, eventuell verwendeten Testkonten und Testdaten.
  • Achte darauf, dass du voneinander unabhängige Sicherheitslücken in separaten Tickets meldest.
  • Gib deinem Bericht einen klaren Titel, der die Sicherheitslücke beschreibt.
  • Dein Bericht muss schriftliche Anweisungen zur Reproduktion der Sicherheitslücke enthalten. Berichte, die keine eindeutigen Reproduktionsschritte oder nur einen Video-PoC enthalten, können von der Prämie ausgeschlossen werden.

Kompensation

Du hast eventuell Anspruch auf eine Geldprämie, wenn du folgende Voraussetzungen erfüllst:
    • Du bist die erste Person, die uns eine bestimmte Sicherheitslücke eines Produkts meldet.
    • Die Sicherheitslücke wird von unserem Team als relevantes Sicherheitsproblem eingestuft.
    • Du hast dich an alle Programmregeln gehalten.

Alle Prämienbeträge werden von unserem Team festgelegt, das jeden Bericht bewertet und eine Kritikalitätsstufe zuweist. Diese bestimmt die Höhe der zu erhaltenden Geldprämie. Die Kritikalitätsstufen werden intern auf der Grundlage der Art der Sicherheitslücke und des Gefahrenpotenzials, das von ihr ausgeht, festgelegt. Nachfolgend findest du eine Übersicht von Beispielen für jede Kritikalitätsstufe:

  • Nicht sicherheitsbezogene Probleme, z. B. Nicht-200-HTTP-Statuscodes, App- oder Server-Fehler
  • Probleme ohne eindeutiges Sicherheitsrisiko, z. B. CSRF im ausgeloggten Zustand, fehlende HTTP-Sicherheits-Header, SSL-Probleme, Probleme mit der Passwortrichtlinie oder Clickjacking auf Seiten ohne sensible Aktionen.
  • Probleme, die veraltete Apps oder Komponenten betreffen, die nicht mehr verwendet oder gewartet werden
  • Probleme, die Dritte betreffen, wie Apps oder von uns verwendete Dienste Dritter (z. B. Firebase oder ZenDesk)
  • Probleme mit Spam oder Social-Engineering-Techniken, z. B. SPF und DKIM sowie fehlende DNSSEC.
  • Probleme mit der Offenlegung von Server-Informationen, sprich `X-Powered-by` und `Server` Response Header. Ausnahmen können bestehen, wenn die offengelegten Informationen eine Serverversion mit einer zugehörigen CVE-Offenlegung enthalten.
  • Probleme mit Server-Side Request Forgery (SSRF) bei Diensten, die standardmäßig aktive Anfragen durchführen, es sei denn, es kann nachgewiesen werden, dass sensible Informationen durchsickern können.
  • Bugs, welche eine unwahrscheinliche User-Interaktion voraussetzen, z. B. Kontoübernahme durch SSO-Anmeldung.
  • Berichte, die einen privilegierten Zugriff auf die Geräte der Zielperson erfordern oder anderweitig außerhalb unserer Kontrolle liegen. Dazu gehört: Zugriff auf Browser-Cookies und/oder andere Token, die verwendet werden, um sich als User auszugeben, Zugriff auf die E-Mail-Adresse des Users usw.
  • Clickjacking-Probleme, die auf vorab authentifizierten Seiten auftreten, oder fehlende `X-Frame-Options` oder andere nicht manipulierbare Clickjacking-Probleme.
  • Probleme beim Cross-OriginResourceSharing (CORS), wenn der Server NICHT mit dem Header `Access-Control-Allow-Credentials: true` antwortet.
  • Fehlende Ratenbegrenzung, sofern dies nicht zu einer angreifbaren Sicherheitslücke führen kann.
  • Auflistung der User-E-Mails auf den Seiten „Registrieren“, „Anmelden“ und „Passwort vergessen“.
  • Dateien, die in URIs verfügbar sind, deren Pfad mit `/.well-known` beginnt (auch als Well-Known URIs bekannt).
  • 2FA-Umgehung durch Zurücksetzen des Passworts
  • Spezifische Probleme bei Client-Apps
    • Unverschlüsselt gespeicherte User-Daten
    • Fehlende Obfuskation
    • Laufzeit-Exploits, bei denen die Ausführung des Codes oder die Umgebung manipuliert wird
  • Offene Weiterleitungen
  • Fehlkonfiguration der Server oder Bereitstellungsfehler
  • Datenlecks und Offenlegung von Daten mit Ausnahme sensibler User-Daten
  • Probleme beim Cross-OriginResourceSharing (CORS), wenn ein Server mit einem `Access-Control-Allow-Credentials: true`-Header auf eine Anfrage mit einem `Origin`-Header eines Drittanbieters antwortet (d. h. nicht `*.todoist.com`, `*.twist.com`).
  • Reflektiertes XSS
    • Probleme mit Mixed Content, wenn die Ziel-URL nicht mit einem Sicherheitsheader (Strict-Transport-Security, HSTS) antwortet. Das Risiko besteht weiterhin, ist aber auf eine einzige Interaktion pro Domäne/Unterdomäne (je nach HSTS-Wert) beschränkt. Im Jahr 2021 sind die Browser zu einem HTTPS-Standard übergegangen, was dieses Problem weiter entschärft.
  • Andere Probleme mit geringer Kritikalität
  • CSRF/XSRF
  • SSRF bei einem internen Dienst
  • Beständiges XSS
  • Andere Probleme mit mittlerer Kritikalität
  • Datenlecks und Offenlegung von Daten einschließlich sensibler User-Daten
  • Andere Probleme mit hoher Kritikalität
  • SQL-Injection
  • Remote-Code-Ausführung
  • Rechteausweitung
  • Sicherheitslücken, die durch Fehler bei der Implementierung der Authentifizierungs- und der Sitzungsverwaltung verursacht werden
  • Durch SSRF bei einem internen Dienst entstehende kritische Sicherheitsrisiken
  • Andere Probleme mit kritischer Kritikalität
AppKeineNiedrigMittelHochKritisch
Todoist0 $100 $200 $500 $1000 $
Twist0 $50 $100 $250 $500 $

Solltest du eine Sicherheitslücke bei einer unserer mobilen Android-Apps entdeckt haben, hast du möglicherweise Anspruch auf eine zusätzliche Prämie über das folgende Programm: Google Play Security Rewards Program.

Alle Prämien werden über PayPal ausgezahlt.

Das Team von Doist behält sich das Recht vor, zu entscheiden, ob die gemeldete Sicherheitslücke als zulässig eingestuft wird.

Alle vom zuständigen Doist-Team getroffenen Entscheidungen über die Höhe einer Prämie sind endgültig.

Kontakt

Eine Sicherheitslücke melden