Richtlinie zur Offenlegung von Software-Schwachstellen

Relution – Richtlinie zur Offenlegung von Software-Schwachstellen

1. Einleitung

Die Sicherheit unserer Produkte und Dienste sowie der Schutz der uns anvertrauten Kundendaten haben für Relution höchste Priorität. Unabhängige Sicherheitsforschende leisten einen wertvollen Beitrag, indem sie Schwachstellen aufdecken, die andernfalls unentdeckt bleiben könnten.

In dieser Richtlinie erfahren Sie, wie Sie autorisiert nach Schwachstellen suchen können, wie Sie uns Ihre Erkenntnisse melden und was Sie im Gegenzug von uns erwarten können. Wir schätzen die Mitarbeit all jener, die in gutem Glauben dazu beitragen, unsere Plattform für alle sicherer zu machen.

Die Richtlinie kann von Zeit zu Zeit aktualisiert werden; Datum des Inkrafttretens und Versionsnummer werden dabei entsprechend angepasst. Bitte lesen Sie die jeweils aktuelle Fassung, bevor Sie mit Tests beginnen.

2. Geltungsbereich

2.1 Einbezogene Systeme

Folgende Ressourcen fallen in den Geltungsbereich dieser Richtlinie:

  • Die Relution-Plattform und die zugehörigen Dienste, die unter von Relution betriebenen Domains gehostet werden
  • Von Relution unter *.relution.io betriebene Webanwendungen und Portale
  • Die von Relution auf Docker Hub veröffentlichten Docker-Container
  • Von Relution in offiziellen App Stores veröffentlichte mobile Anwendungen
  • Öffentliche APIs, dokumentiert unter https://live.relution.io/web-api/index.html (Registrierung erforderlich)
  • Die Relution-Website und zugehörige Webseiten wie der Relution Hub

2.2 Ausgenommene Systeme

Folgende Ziele sind im Rahmen dieser Richtlinie nicht für Tests autorisiert:

  • Relution-Software, die von unseren Kunden, Partnern oder Dritten betrieben wird
  • Sonstige Systeme, Netzwerke oder Anwendungen unserer Kunden, Partner oder Dritter
  • In unsere Plattform eingebundene Drittanbieterdienste (z. B. Zahlungsdienstleister, Identitätsanbieter, Analysedienste)
  • Physische Räumlichkeiten und Einrichtungen der Relution GmbH

Falls unklar ist, ob ein Ziel in den Geltungsbereich fällt, wenden Sie sich bitte vor Beginn jeglicher Tests an security@relution.io.

3. Verhaltensregeln

3.1 Autorisierte Aktivitäten

Bei Einhaltung dieser Richtlinie sind folgende Aktivitäten ausdrücklich gestattet:

  • Auswertung öffentlich zugänglicher Informationen zu unseren Systemen (z. B. DNS-Einträge, SSL-Zertifikate, öffentlich verfügbare Dokumentation)
  • Tests auf gängige Schwachstellen in Webanwendungen (z. B. Injection-Schwachstellen, Authentifizierungsmängel, Zugriffskontrollprobleme, Sicherheitsfehlkonfigurationen)
  • Untersuchung von API-Endpunkten auf Sicherheitslücken
  • Analyse von clientseitigem Code, der über unsere Webanwendungen ausgeliefert wird
  • Sofern die betreffenden Artefakte von Relution stammen und auf legitimem Weg über offizielle Distributionskanäle bezogen wurden:
    • Analyse von Docker-Containern und deren Inhalten
    • Reverse Engineering einschließlich Dekompilierung von mobilen Anwendungen sowie Java-Archiven und zugehörigen Klassendateien

3.2 Voraussetzungen für die Autorisierung

Um im Rahmen dieser Autorisierung zu handeln, müssen Sie:

  1. In gutem Glauben handeln – mit dem alleinigen Ziel, Sicherheitslücken zu identifizieren und zu melden
  2. Schäden minimieren: Vermeiden Sie Handlungen, die die Verfügbarkeit von Systemen, die Datenintegrität oder andere Nutzende beeinträchtigen könnten
  3. Bei Entdeckung abbrechen: Sobald das Vorhandensein einer Schwachstelle bestätigt ist, stellen Sie weitere Tests ein und melden Sie Ihre Erkenntnisse; versuchen Sie nicht, die Auswirkung durch Zugriff auf weitere Daten oder Systeme zu demonstrieren
  4. Daten schützen: Greifen Sie nicht auf Daten anderer Nutzender zu und kopieren, verändern oder löschen Sie diese nicht; sollten Sie versehentlich auf solche Daten stoßen, brechen Sie sofort ab, speichern oder teilen Sie die Daten nicht und vermerken Sie den Vorfall in Ihrem Bericht
  5. Vertraulichkeit wahren: Geben Sie keine Details zu Schwachstellen an Dritte weiter, bevor wir angemessen Gelegenheit hatten, das Problem zu beheben, und eine koordinierte Offenlegung vereinbart wurde

3.3 Untersagte Aktivitäten

Folgende Methoden und Verhaltensweisen sind unter keinen Umständen gestattet – auch nicht gegenüber einbezogenen Systemen:

  • Jede Form von Social Engineering, Phishing, Vishing, Pretexting oder vergleichbaren Methoden gegenüber Beschäftigten oder Nutzenden von Relution
  • Physisches Eindringen oder Versuche, sich physisch Zugang zu verschaffen
  • Denial-of-Service-Angriffe (DoS/DDoS) oder Tests, die auf eine Beeinträchtigung der Dienstverfügbarkeit abzielen
  • Automatisierte Schwachstellenscans in einem Umfang oder einer Häufigkeit, die die Systemleistung beeinträchtigen könnten
  • Zugriff auf, Herunterladen oder anderweitiges Abgreifen von Kundendaten, personenbezogenen Daten oder vertraulichen Geschäftsinformationen
  • Verändern oder Löschen von Daten in jeglichen Systemen
  • Hochladen von Schadcode, Hintertüren oder Mechanismen für dauerhaften Zugriff
  • Versuche, ausgehend von einer entdeckten Schwachstelle auf weitere Systeme oder Daten zuzugreifen
  • Spam oder unaufgeforderte Massennachrichten
  • Weitergabe von Zugangsdaten, Schwachstellendetails oder Proof-of-Concept-Code an Dritte
  • Öffentliche Offenlegung von Schwachstellen, bevor eine koordinierte Offenlegung vereinbart wurde

4. Rechtliche Position

Gegenüber Sicherheitsforschenden, die diese Richtlinie vollständig einhalten, verpflichtet sich Relution:

  • Keine zivilrechtlichen Schritte einzuleiten für Aktivitäten, die im Einklang mit dieser Richtlinie durchgeführt wurden
  • Keine Strafanzeige zu erstatten für Aktivitäten, die im Einklang mit dieser Richtlinie durchgeführt wurden
  • In gutem Glauben zusammenzuarbeiten bei der Bearbeitung gemeldeter Schwachstellen
  • Auf Anfrage eine Autorisierungsbestätigung auszustellen, damit Forschende ihren Status vor Beginn der Tests dokumentieren können

Diese Richtlinie stellt eine Autorisierung durch Relution als Betreiberin der in Abschnitt 2.1 beschriebenen Systeme dar. Wir haben sie in gutem Glauben erstellt, um Forschende zu schützen, die ebenfalls in gutem Glauben handeln.

Diese Richtlinie kann und wird jedoch keine Immunität vor strafrechtlicher Verfolgung gewährleisten. Wir empfehlen daher dringend, alle Aktivitäten sorgfältig zu dokumentieren und bei Bedenken vor Beginn der Tests eine schriftliche Autorisierungsbestätigung bei uns einzuholen.

5. Verwendung personenbezogener Daten

Die im Rahmen der Schwachstellenmeldung übermittelten personenbezogenen Daten werden ausschließlich zur Untersuchung und Behebung der Schwachstelle verwendet und unterliegen den datenschutzrechtlichen Bestimmungen der Datenschutz-Grundverordnung (DSGVO) und des Bundesdatenschutzgesetzes (BDSG).

6. Meldeverfahren

6.1 Meldung einreichen

Bitte senden Sie Schwachstellenberichte per PGP-verschlüsselter E-Mail an: security@relution.io

Unser öffentlicher PGP-Schlüssel ist unter keys.openpgp.org abrufbar. Der Fingerabdruck lautet: 3594163819E19D4D9FDA35F78BDAB6171E0A12DF.

Darüber hinaus pflegen wir eine security.txt.

6.2 Inhalt des Berichts

Damit wir das Problem rasch nachvollziehen und beheben können, bitten wir um folgende Angaben:

  • Beschreibung der Schwachstelle und ihrer möglichen Auswirkungen
  • Betroffene Systeme: URLs, Anwendungsnamen, Versionsnummern sofern zutreffend
  • Schrittweise Reproduktionsanleitung
  • Proof of Concept: Screenshots, Protokolle oder Codebeispiele, die die Schwachstelle belegen (ohne echte Nutzerdaten)
  • Ihre Einschätzung zu Schweregrad und möglichen Auswirkungen
  • Kontaktdaten für Rückfragen (pseudonyme Angaben sind möglich)
  • Versehentlich eingesehene sensible Daten: Sollten Sie unbeabsichtigt auf personenbezogene oder vertrauliche Daten gestoßen sein, beschreiben Sie bitte das Gesehene, ohne die Daten selbst aufzuführen

Berichte können auf Deutsch oder Englisch eingereicht werden.

6.3 Was der Bericht nicht enthalten sollte

  • Fügen Sie keine tatsächlichen Kundendaten, personenbezogenen Daten oder Zugangsdaten bei
  • Verzichten Sie auf schadhafte Payloads oder funktionsfähigen Exploit-Code, der bei unsachgemäßer Handhabung Schaden verursachen könnte

7. Reaktion und Offenlegung

Nach Eingang Ihres Berichts bestätigen wir den Empfang innerhalb von fünf Werktagen und beginnen mit der Validierung und Einstufung der gemeldeten Schwachstelle.

Bitte räumen Sie uns angemessene Zeit zur Behebung ein: Wir bitten um eine Frist von mindestens 90 Tagen ab der Erstmeldung vor einer öffentlichen Offenlegung. Dies gibt uns Gelegenheit, das Problem zu validieren und zu beheben, die Korrektur zu verifizieren und auf allen Systemen bei allen Kunden auszurollen.

Bei Bedarf setzen wir uns über die etablierten Kanäle mit Ihnen in Verbindung, um zusätzliche Informationen einzuholen. Über den Fortschritt der Untersuchung und Behebung halten wir Sie auf dem Laufenden.

Wird die Schwachstelle bestätigt, vergeben wir eine interne REL-Kennnummer, die in der weiteren Kommunikation und in späteren Sicherheitshinweisen als Referenz dient.

Nach Behebung der Schwachstelle stimmen wir mit Ihnen Zeitpunkt und Details der Offenlegung ab.

8. Anerkennung und Vergütung

Wir betreiben derzeit kein monetäres Bug-Bounty-Programm. Die Einführung eines solchen Programms ist für die Zukunft nicht ausgeschlossen; diese Richtlinie wird in diesem Fall entsprechend aktualisiert.

Forschende, die im Einklang mit dieser Richtlinie eine bestätigte Schwachstelle melden, haben derzeit Anspruch auf:

  • Öffentliche Anerkennung auf unserer Seite für Sicherheitshinweise (mit Ihrer Zustimmung)
  • Namentliche Erwähnung in Sicherheitshinweisen zur gemeldeten Schwachstelle (mit Ihrer Zustimmung)
  • Ein Dankesschreiben, das sich für berufliche Portfolios eignet (auf Anfrage)

Anhang: Beispiele für Schwachstellen

Die folgenden Beispiele sollen veranschaulichen, welche Arten von Schwachstellen in den Geltungsbereich dieser Richtlinie fallen und welche nicht.

Qualifizierende Schwachstellen

  • Remote Code Execution
  • SQL-Injection und andere Injection-Schwachstellen
  • Fehler in der Authentifizierung oder Sitzungsverwaltung
  • Umgehung von Autorisierungsmechanismen und Rechteausweitung
  • Cross-Site Scripting (XSS) mit nachgewiesener Auswirkung
  • Cross-Site Request Forgery (CSRF) mit nachgewiesener Auswirkung
  • Offenlegung sensibler Daten
  • Sicherheitsfehlkonfigurationen mit erkennbarer Auswirkung
  • Server-Side Request Forgery (SSRF)
  • Unsichere direkte Objektreferenzen

Nicht qualifizierende Meldungen

Folgende Punkte gelten in der Regel nicht als qualifizierende Schwachstellen:

  • Schwachstellen, die physischen Zugriff auf das Gerät eines Nutzenden erfordern
  • Schwachstellen in Anwendungen oder Diensten von Drittanbietern
  • Social-Engineering-Angriffe
  • Denial-of-Service-Schwachstellen (bitte dennoch melden; aufgrund der Testbeschränkungen sind sie im Rahmen dieser Richtlinie jedoch nicht anerkennungsfähig)
  • Durch automatisierte Scanner identifizierte Probleme ohne nachgewiesene Ausnutzbarkeit
  • Fehlende Sicherheitsheader ohne nachgewiesene Auswirkung
  • Clickjacking ohne nachgewiesene sicherheitsrelevante Aktion
  • Self-XSS (Skriptausführung nur in der eigenen Sitzung möglich)
  • CSRF bei nicht sicherheitsrelevanter Funktionalität
  • Offenlegung nicht sensibler Informationen
  • Offenlegung von Softwareversionen ohne zugehörige Schwachstelle
  • Theoretische Schwachstellen ohne Proof of Concept
  • Bereits bekannte oder zuvor gemeldete Schwachstellen