Zum Inhalt springen

Informationen zum TYPO3 Sicherheitsupdate vom 10. August 2021 (Update)

Am 10. August 2021 wurden Updates für TYPO3 Version 7 bis 11 veröffentlich. Diese machen TYPO3 Webseiten sicherer, führen allerdings auch bei manchen Anwendern zu unerwünschten Nebeneffekten. 

In der Regel werden die bei uns gehosteten TYPO3 Versionen automatisch aktualisiert. Unsere Kunden müssen sich dabei nicht um die technischen Details kümmmern.

Sicherheits-Updates werden dabei innerhalb von 24 Stunden vorgenommen, bei regulären Updates warten wir zunächst ein paar Tage.

Warum warten? Nun, es kommt manchmal vor, dass ein Update bei manchen Installationen zu unerwünschten Effekten führen kann. Die neuen Versionen werden zwar vom TYPO3 Entwicklerteam und auch von uns getestet, bevor die Installation bei unseren Kunden erfolgt. Da Webseiten aber ganz unterschiedlich konfiguriert sind und oftmals individuelle Erweiterungen haben, können nicht alle Variationen mit Tests abgedeckt werden. 

Bei normalen Updates mit Fehlerbehebungen warten wir daher ein paar Tage und beobachten den TYPO3 Bug-Tracker, Foren, Slack- und Social Media Kanäle. Erst wenn dort keine Vorkommnisse gemeldet werden, verteilen wir die neuen Versionen bei unseren Kunden. 

Beim Sicherheits-Update vom 10. August gab es jedoch ein paar Meldungen über Inkompatibilitäten, so dass wir die neuen Versionen noch nicht ausgerollt haben. Wir warten daher, bis in einigen Tagen neue Updates erscheinen. Jeder Kunde hat immer die Option ein Update selbst zu installieren. Update: Inzwischen wurden die TYPO3 Versionen 10.4.20, 9.5.30, 8.7.43 und 7.6.54 veröffentlicht. Diese sollen die gemeldeten Probleme beheben. 

Hier noch die Übersetzung eines Artikels, der am 14. August auf typo3.org veröffentlicht wurde:

Die am Dienstag, den 12. August 2021, veröffentlichten Sicherheitsversionen enthalten eine sehr wichtige Fehlerbehebung. Sie entfernt bösartigen und falschen HTML-Code aus Rich-Text-fähigen Feldern. Allerdings hat es auch Probleme bei einer Reihe von Webseiten verursacht.

Wir vom TYPO3 Core Team und dem Security Team waren froh, dass mit dem Release endlich eine sichere Lösung für dieses seit langem bestehende, schwerwiegende Problem gefunden wurde. Aber vielleicht war sie zu sicher? Wir wurden bald von Leuten aus der TYPO3-Community kontaktiert, die uns von Situationen berichteten, in denen der Sanitizer zu viel oder an den falschen Stellen bereinigt hat.

In diesem Artikel schauen wir uns an, was die Sicherheitsversion behebt, was die Probleme verursacht und wie man sie löst.

Was ist ein Rich-Text-aktiviertes Feld?

Ein Rich-Text-aktiviertes Feld, auch RTE-Inhalt genannt, ist ein Feld, in das Redakteure Formatierungen, Links, Tabellen usw. einfügen können. Sie werden es wahrscheinlich als das prominenteste Textfeld in den Inhaltselementen Text oder Text mit Medien erkennen. Der Rich-Text-Editor verwendet HTML-Code, und ohne Bereinigung wäre es möglich, ihn zu nutzen, um bösartigen Code in eine Seite einzufügen.

Was war das Sicherheitsproblem?

Rich-Text-fähige Felder formatieren Text mit HTML-Code, und ohne Bereinigung wäre es möglich, damit bösartigen Code auf einer Seite einzufügen. Dies ist ähnlich wie bei anderen Arten von benutzerdefinierten Inhalten, z. B. bei Feldern in Feedback-Formularen, bei denen die eingegebenen Informationen noch einmal als Vorschau angezeigt werden, bevor die E-Mail versendet und in der Datenbank gespeichert wird.

Vor der Sicherheitsfreigabe verwendete TYPO3 ein Ausschlusskonzept namens RemoveBadXSS. Es ist keine sichere Lösung, da es den HTML Code nicht analysiert, sondern einfach reguläre Ausdrücke verwendet, um nach bösartigem HTML zu suchen.

Wie wurde es behoben?

Wir haben einen Sanitizing-Parser als separates PHP-Paket namens typo3/html-sanitizer implementiert. Es handelt sich um einen Parser, der auf einer Erlaubnis-Liste anstelle einer Verbots-Liste basiert. 

Ziel des HTML-Sanitizers ist es, unerwünschten HTML-Code zu entfernen, der zu Cross-Site-Scripting (XSS) führen könnte, einer häufigen und ernsthaften Sicherheitslücke. Cross-Site-Scripting-Angriffe können andere Sicherheitslücken ausnutzen, so dass ein Redakteur potenziell bösartigen HTML-Code einfügen kann, ohne es zu wissen. Aus diesem Grund ist die Bereinigung des übermittelten HTML-Codes so wichtig.

Wir haben mehr als acht Jahre lang nach einer guten und leistungsfähigen Lösung gesucht, aber bis jetzt nie ein flexibles, schnelles und gut gewartetes Paket gefunden.

Wir haben eine Standard-Erlaubnisliste für den HTML Sanitizer implementiert und ihn dann an zwei Stellen eingesetzt:

A: Ein Backend-Benutzer speichert RTE-Inhalte in der Datenbank

Früher haben wir uns auf die Sanitization-Logik von CKEditor verlassen, aber diese verwendet eine clientseitige Validierung, der nicht immer vertraut werden kann. Dies wird nun bereinigt und auf die Serverseite verlagert. Bei jedem Speichern wird der eingehende HTML-Code bereinigt. Ein globale Einstellung "rte.htmlSanitize" wurde hinzugefügt und standardmäßig aktiviert.

B: Beim Rendern von HTML-Inhalten aus einem RTE-Feld auf der Website wird die so genannte parseFunc-Logik ebenfalls den HTML-Sanitizer aufrufen. parseFunc wird verwendet, um HTML-Tags umzuschreiben (z.B. TYPO3-interne Links zu Seiten), und es wird auch im <f:format.html> ViewHelper verwendet.

Was sind die Probleme?

1. Die Zulässigkeitsliste des HTML-Sanitizers enthielt Bugs
Die meisten der gemeldeten Probleme betrafen erweiterte CKEditor-Plugins oder die Tatsache, dass wir keine Tests für spamProtectedEmailAdresses vorgesehen hatten (die Sie in 2021 deaktivieren können und sollten, da die meisten Bots mit dieser "obskuren" Logik umgehen können). Dank der vielen Berichte konnten wir diese Probleme schnell beheben.

2. Leute benutzten parseFunc an Stellen, wo sie es nicht sollten
lib.parseFunc war unserer Meinung nach eine Funktion zum Parsen von RTE-Inhalten, aber die Leute nutzten <f:format.html> und parseFunc für viele andere innovative Lösungen. Sie können parseFunc verwenden, um:

  • Ersetzen eines HTML-Tags (z.B. <b> durch<em>)
  • Hinzufügen von Standard-CSS-Klassen zu allen Tabellenzellenelementen
  • Hinzufügen von benutzerdefinierten Tags nach jedem <figure>-Tag

In der Tat kann lib.parseFunc für jede HTML-Ersetzungslogik verwendet werden, auch wenn es andere Lösungen gibt, wie z.B. die Ersetzungsoption von TypoScript. Es gibt wirklich tausend Möglichkeiten, eine einzige Aufgabe in TYPO3 zu lösen!

Wir hatten mehrere Remote-Sitzungen mit betroffenen Benutzern, die mit dem neuen Verhalten zu kämpfen hatten. Diese Sitzungen lieferten wichtige und hilfreiche Einblicke in Anwendungsfälle und Anforderungen. Die folgende Liste gibt einen Überblick über das, was bis jetzt passiert ist:

  • Fehlersuche und Sammlung technischer Details
  • Tracking-Ticket für Fehlerberichte und entsprechende Pull-Requests
  • Pull-Request zur Lockerung des Sanitization-Verhaltens. Wir brauchen dringend Feedback und weitere Tests durch die Community.

Lösungen sind in Arbeit - Tester werden benötigt

Wir planen eine Regressions-Bugfix-Veröffentlichung (11.3.3, 10.4.20, 9.5.30) so bald wie möglich, sobald genügend Leute unsere vorgeschlagenen Änderungen überprüft haben. 

Wir werden auch einen neuen ViewHelper für Fluid ausliefern: <f:sanitize.html>. Er kann verwendet werden, wenn man einfach nur sicherstellen will, dass es sicher ist, von Nutzern eingereichte Inhalte erneut zu rendern.

Wir sind uns bewusst, dass nur eine kleine Gruppe von Personen die Sicherheitskorrekturen vor der Veröffentlichung testen kann, insbesondere in realen Projekten mit viel benutzerdefiniertem Code. Wir sind aktiv auf der Suche nach Entwicklern und Unternehmen, die uns dabei helfen, Sicherheitsänderungen zu testen, bevor sie veröffentlicht werden. Bitte wenden Sie sich an security(at)typo3.org, wenn Sie uns helfen möchten, Änderungen vor der Veröffentlichung zu testen.

Wir benötigen Beiträge für die Dokumentation von Best Practices, z.B. wie man den richtigen ViewHelper für eine bestimmte Situation auswählt, und wie man Daten in Templates besser strukturiert und trennt.

Fazit

Es tut uns leid, dass die Sicherheitsversion für viele von Euch Probleme verursacht hat, aber wir sind auch sehr dankbar für alle, die durch ihre Beiträge und ihr Feedback geholfen haben. Ihr habt TYPO3 stärker gemacht als je zuvor.

(Der Originalbeitrag in Englisch wurde verfasst von Oliver Hader und Benni Mack mit Hilfe von Mathias Bolt Lesniak)

Sicherheitsmeldung vom 10. August 2021 (englisch)

Vorhängeschloss an einem rostigen Türverschluss

Sicherheit ist ein wichtiges Thema für Webseiten. Mögliche Einfallstore für Angreifer sollten daher immer gut verschlossen sein.