Schwachstellen-Offenlegung

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.

Diese Richtlinie beschreibt, wie sich autorisiert nach Schwachstellen suchen lässt, wie uns Erkenntnisse gemeldet werden können und was im Gegenzug von uns erwartet werden kann. 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. Vor Beginn der Tests bitte die jeweils aktuelle Fassung lesen.

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, bitte vor Beginn jeglicher Tests an security@relution.io → wenden.

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, ist Folgendes erforderlich:

1. In gutem Glauben handeln – mit dem alleinigen Ziel, Sicherheitslücken zu identifizieren und zu melden
2. Schäden minimieren: Handlungen vermeiden, 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, weitere Tests einstellen und die Erkenntnisse melden; die Auswirkung nicht durch Zugriff auf weitere Daten oder Systeme demonstrieren
4. Daten schützen: Nicht auf Daten anderer Nutzender zugreifen und diese nicht kopieren, verändern oder löschen; bei versehentlichem Zugriff auf solche Daten sofort abbrechen, die Daten nicht speichern oder teilen und den Vorfall im Bericht vermerken
5. Vertraulichkeit wahren: Keine Details zu Schwachstellen an Dritte weitergeben, 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 #

Schwachstellenberichte bitte per PGP-verschlüsselter E-Mail senden 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)
• Eigene Einschätzung zu Schweregrad und möglichen Auswirkungen
• Kontaktdaten für Rückfragen (pseudonyme Angaben sind möglich)
• Versehentlich eingesehene sensible Daten: Bei unbeabsichtigtem Zugriff auf personenbezogene oder vertrauliche Daten bitte das Gesehene beschreiben, ohne die Daten selbst aufzuführen

Berichte können auf Deutsch oder Englisch eingereicht werden.

6.3 Was der Bericht nicht enthalten sollte #

• Keine tatsächlichen Kundendaten, personenbezogenen Daten oder Zugangsdaten beifügen
• Auf schadhafte Payloads oder funktionsfähigen Exploit-Code verzichten, der bei unsachgemäßer Handhabung Schaden verursachen könnte

7. Reaktion und Offenlegung #

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

Für die Behebung wird angemessene Zeit benötigt: 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 der meldenden Person in Verbindung, um zusätzliche Informationen einzuholen. Über den Fortschritt der Untersuchung und Behebung wird informiert.

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

Nach Behebung der Schwachstelle werden Zeitpunkt und Details der Offenlegung gemeinsam mit der meldenden Person abgestimmt.

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 Zustimmung der meldenden Person)
• Namentliche Erwähnung in Sicherheitshinweisen zur gemeldeten Schwachstelle (mit Zustimmung der meldenden Person)
• 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