Eine Redakteurin öffnet die Vorschau einer Website und sieht einen unveröffentlichten Beitrag aus einem Bereich, für den sie keine Freigabe hat. Ist eine Rolle falsch konfiguriert? Fehlt eine Berechtigungsprüfung in einer Erweiterung? Oder liegt der Fehler im CMS selbst? Bei Plattformen wie Liferay und Magnolia entscheidet diese Frage darüber, wer die Lücke beheben kann. Für die erste Meldung darf sie offenbleiben.
Was Responsible Disclosure bedeutet
Responsible Disclosure bezeichnet den verantwortungsvollen Umgang mit einer entdeckten Schwachstelle. Der heute häufig verwendete Begriff Coordinated Vulnerability Disclosure (CVD) betont die Abstimmung zwischen den Beteiligten. Wer eine Schwachstelle entdeckt, meldet sie zunächst vertraulich. Die zuständige Stelle prüft den Befund, begrenzt das Risiko und bereitet einen Fix oder eine Übergangslösung vor. Anschließend stimmen die Beteiligten ab, wann betroffene Betreiber oder die Öffentlichkeit welche Informationen erhalten.
Quelle: CERT Guide to Coordinated Vulnerability Disclosure
Bei dieser Abstimmung geht es vor allem um den Zeitpunkt und den Detailgrad. Frühe technische Details können die Ausnutzung erleichtern. Zu langes Schweigen kann Betreibern die Gelegenheit nehmen, sich zu schützen. Ein Sicherheitshinweis kann deshalb zunächst betroffene Versionen und Schutzmaßnahmen nennen. Ein technischer Bericht mit detaillierten Reproduktionsschritten kann später folgen, wenn Betreiber Zeit hatten, den Patch einzuspielen.
Quelle: CERT Guide to Coordinated Vulnerability Disclosure
Meldeprogramm, Bug Bounty und Sicherheitsvorfall
Eine Vulnerability Disclosure Policy beschreibt, welche Systeme und Tests der Betreiber freigibt, wie Meldungen eingehen und was danach passiert. Ein Bug-Bounty-Programm ergänzt diesen Rahmen um mögliche Prämien für qualifizierte Funde. Auch ein kleines Team kann einen verlässlichen Meldeprozess ohne Prämien betreiben. Magnolia und Liferay zeigen beide Varianten.
Quellen: Magnolia Responsible Disclosure Policy · Liferay Reporting and Testing Policy
Eine Schwachstelle ist eine ausnutzbare Schwäche im System. Gibt es Hinweise, dass jemand sie bereits ausnutzt, startet parallel die Bearbeitung des Sicherheitsvorfalls. Das Betriebsteam sichert relevante Protokolle, begrenzt den Zugriff und prüft, welche Systeme und Daten betroffen sind. Die Koordination mit der meldenden Person und dem Hersteller läuft währenddessen weiter.
Quelle: NIST-Leitfaden zum Umgang mit Schwachstellenmeldungen
Warum es mehrere Fristen gibt
Eine Eingangsbestätigung, ein erster belastbarer Status, die Bereitstellung eines Fixes und die Veröffentlichung sind unterschiedliche Meilensteine. Die Eingangsbestätigung kann innerhalb weniger Werktage erfolgen, auch wenn die technische Prüfung länger dauert. Sobald das Team die Auswirkungen besser einschätzen kann, vereinbart es mit der meldenden Person den nächsten Status und einen Zieltermin für die Veröffentlichung.
Die häufig genannten 90 Tage stammen unter anderem aus der Richtlinie von Googles Project Zero. Das Team sieht im regulären Verfahren 90 Tage für einen Patch vor und räumt bei rechtzeitiger Behebung grundsätzlich ein zusätzliches Zeitfenster für dessen Installation ein. Bei beobachteter aktiver Ausnutzung gelten kürzere Fristen. Welche Frist für einen konkreten Fall passt, hängt unter anderem vom Risiko und den verfügbaren Schutzmaßnahmen ab.
Quelle: Project Zero Vulnerability Disclosure Policy
Wenn der zuständige Anbieter trotz Kontaktversuchen nicht reagiert oder mehrere Anbieter dieselbe Komponente einsetzen, kann eine Koordinierungsstelle wie ein zuständiges CERT helfen. Sie kann Kontakte herstellen und die Information mehrerer betroffener Parteien abstimmen. Das ist etwa dann relevant, wenn ein Fehler in einer Bibliothek steckt, die über verschiedene CMS-Erweiterungen ausgeliefert wird.
Quelle: CERT Guide to Coordinated Vulnerability Disclosure
Wer ist bei einem CMS zuständig?
Ein CMS-Projekt besteht aus dem Produkt, projektspezifischem Code, Rollen und Berechtigungen, Schnittstellen sowie der Hosting-Infrastruktur. Die erste Zuordnung gelingt häufig über die Frage, unter welchen Bedingungen sich der Fehler reproduzieren lässt.
| Befund | Erste Anlaufstelle |
|---|---|
| Der Fehler tritt auch in einer sauberen Testinstallation mit Standardkomponenten auf. | Hersteller oder Security-Team des Produkts |
| Der Fehler tritt nur mit einem eigenen Liferay-Modul, einer Magnolia-Erweiterung oder einer projektspezifischen Konfiguration auf. | Betreiber und zuständiges Projektteam |
| Der Befund betrifft eine Drittanbieter-Erweiterung oder einen vorgeschalteten Dienst. | Betreiber zur Risikobegrenzung und Anbieter der betroffenen Komponente zur Fehlerbehebung |
Wer eine Schwachstelle auf einer konkreten Website entdeckt und die Ursache noch nicht kennt, meldet sie vertraulich an deren Betreiber. Dieser kann die Instanz absichern und den Hersteller bei Bedarf einbeziehen. Eine Reproduktion in einer freigegebenen Standardinstallation hilft, Produktfehler und Projektkonfiguration voneinander zu unterscheiden.
So setzen CMS-Betreiber den Prozess auf
1. Einen auffindbaren Meldeweg veröffentlichen
Eine kurze Richtlinie nennt eine betreute Security-Adresse oder ein geschütztes Formular. Sie legt fest, welche Domains und Umgebungen erfasst sind, welche Tests zulässig sind und wie sensible Nachweise sicher übermittelt werden können. Typische Grenzen betreffen die Verfügbarkeit, Änderungen an fremden Daten und den Zugriff auf personenbezogene Inhalte. Betreiber mit mehreren Dienstleistern sollten intern klären, wer Meldungen annimmt und wer auf welcher Plattform Änderungen vornehmen kann.
Eine über HTTPS erreichbare Datei unter /.well-known/security.txt macht den Meldeweg maschinenlesbar. Contact und Expires sind Pflichtfelder. Policy kann auf die Richtlinie verweisen. Die Datei gilt grundsätzlich für den Host, auf dem sie bereitgestellt wird. Bei mehreren öffentlichen CMS-Domains sollte der Meldeweg deshalb auf jedem relevanten Host auffindbar sein.
Quelle: RFC 9116 zu security.txt
2. Einen reproduzierbaren Bericht annehmen
Ein brauchbarer Bericht enthält die betroffene URL oder Komponente, die genaue Produkt- und Modulversion, die benötigte Rolle, die Schritte zur Reproduktion sowie das erwartete und das beobachtete Verhalten. Ein konkreter Satz zur Auswirkung hilft bei der Einordnung, etwa dass ein Redaktionskonto einen unveröffentlichten Beitrag aus einem fremden Bereich lesen kann.
Für den Nachweis genügen oft Testdaten oder ein geschwärzter Screenshot. Sobald der Befund belegt ist, endet der Test. Wer dabei unerwartet auf echte Kundendaten stößt, bricht die Prüfung ab und meldet den Zugriff über den geschützten Kanal.
3. Zuständigkeit und Dringlichkeit klären
Jede Meldung erhält ein vertrauliches Ticket, eine verantwortliche Person und eine Vertretung. Zwei Werktage bis zur Eingangsbestätigung können für ein kleines CMS-Team ein praktikables internes Ziel sein. Bei der anschließenden Bewertung zählt, ob die Funktion öffentlich erreichbar ist, welche Rolle für die Ausnutzung nötig ist, wie viele Instanzen betroffen sind und welche Daten oder Funktionen auf dem Spiel stehen. Ein öffentlich erreichbarer Endpunkt, der unveröffentlichte Inhalte ausliefert, erfordert eine andere Reaktion als derselbe Fehler in einer isolierten Testumgebung.
Quelle: NIST-Leitfaden zur Bearbeitung von Schwachstellen
4. Das Risiko begrenzen und den Fix überprüfen
Das Team kann den Zugriff vorübergehend einschränken, eine betroffene Funktion deaktivieren oder einen verfügbaren Patch einspielen. Für die Prüfung des Fixes verwendet es dieselbe Rolle und denselben Ablauf, mit denen sich die Lücke nachweisen ließ. Bei einem Berechtigungsfehler gehört eine Gegenprobe dazu. Berechtigte Nutzer müssen weiterhin auf die Funktion zugreifen können. Betreibt das Team mehrere Instanzen, erfasst es auch, wo der Fix bereits installiert wurde und wo eine Übergangslösung greift.
5. Betroffene informieren und die Veröffentlichung abstimmen
Betreiber, Hersteller und meldende Person stimmen ab, wer wann informiert wird. Ein Security Advisory nennt üblicherweise die betroffenen Versionen, die Auswirkungen, verfügbare Schutzmaßnahmen und die korrigierte Version. Wenn ein Fix länger dauert, hält das Team die meldende Person auf dem Laufenden und vereinbart den nächsten Termin. Bei aktiver Ausnutzung kann eine frühere Warnung mit konkreten Schutzmaßnahmen sinnvoll sein.
Quelle: CERT Guide to Coordinated Vulnerability Disclosure
Die Meldewege bei Liferay und Magnolia
Liferay verweist für externe Sicherheitsmeldungen auf sein öffentliches Bug-Bounty-Programm bei Intigriti. Dort stehen die geltenden Regeln und die ausdrücklich erfassten Ziele. Für DXP-Vertragskunden beschreibt Liferay zusätzlich den Weg über die Subscription Services im Customer Portal. Wer eine konkrete Kundeninstallation testen möchte, richtet sich nach der Freigabe des jeweiligen Betreibers.
Quellen: Liferay Reporting and Testing Policy · Liferay Security Support Policy
Magnolia nennt für Schwachstellen im Produkt ein privates SUPPORT-Ticket oder die Adresse security@magnolia-cms.com. Die separate Responsible-Disclosure-Richtlinie für Domains und Subdomains im Eigentum von Magnolia grenzt den Testumfang ein und verlangt englischsprachige Berichte mit einem nachvollziehbaren Angriffsszenario. Bei einer vom Kunden betriebenen Magnolia-Website ist dessen eigener Meldeweg die erste Anlaufstelle.
Quellen: Magnolia Security Policy · Magnolia Responsible Disclosure Policy
Zurück zur Vorschau
Der Betreiber prüft mit zwei Testkonten und einem unveröffentlichten Testinhalt, ob die Vorschau tatsächlich die vorgesehene Bereichsgrenze überschreitet. Tritt der Fehler nur in einer eigenen Erweiterung auf, korrigiert das Projektteam die Berechtigungsprüfung. Lässt er sich auch mit der Standardfunktion reproduzieren, erhält der Hersteller einen vertraulichen Bericht mit Versionen und Reproduktionsschritten.
Bis zur Klärung kann der Betreiber den Zugriff auf die Vorschau einschränken. Nach dem Fix prüft er beide Rollen erneut und informiert die meldende Person über das Ergebnis. Damit kommt der Hinweis dort an, wo das Risiko zuerst gesenkt und die Ursache anschließend behoben werden kann.
