Information about the TYPO3 security update from August 10, 2021 (Update)

As a rule, the TYPO3 versions hosted by us are updated automatically. Our customers do not have to worry about the technical details.

Security updates are carried out within 24 hours, while we wait a few days for regular updates.

Why wait? Well, it sometimes happens that an update can lead to undesirable effects in some installations. The new versions are tested by the TYPO3 development team and by us before they are installed for our customers. However, as websites are configured very differently and often have individual extensions, not all variations can be covered by tests.

For normal updates with bug fixes, we therefore wait a few days and monitor the TYPO3 bug tracker, forums, Slack and social media channels. Only when no incidents are reported there do we distribute the new versions to our customers.

During the security update on August 10, however, there were a few reports of incompatibilities, so we have not yet rolled out the new versions. We are therefore waiting until new updates are released in a few days. Every customer always has the option to install an update themselves. Update: In the meantime the TYPO3 versions 10.4.20, 9.5.30, 8.7.43 and 7.6.54 have been released. These should fix the reported problems.

Here is the translation of an article that was published on typo3.org on August 14th:

The security versions released on Tuesday, August 12, 2021, contain a very important bug fix. It removes malicious and incorrect HTML code from rich text-enabled fields. However, it has also caused problems for a number of websites.

We at the TYPO3 Core Team and the Security Team were happy that the release finally provided a secure solution to this long-standing, serious problem. But maybe it was too secure? We were soon contacted by people from the TYPO3 community who told us about situations where the sanitizer was sanitizing too much or in the wrong places.

In this article, we look at what the security release fixes, what causes the issues and how to resolve them.

What is a rich text enabled field?

A rich text-enabled field, also known as RTE content, is a field that editors can insert formatting, links, tables, etc. into. You will probably recognize it as the most prominent text field in the Text or Text with media content elements. The rich text editor uses HTML code, and without cleanup, it would be possible to use it to insert malicious code into a page.

What was the security issue?

Rich text-enabled fields format text with HTML code, and without sanitization it would be possible to use it to insert malicious code into a page. This is similar to other types of custom content, such as fields in feedback forms where the information entered is previewed again before the email is sent and stored in the database.

Before the security release, TYPO3 used an exclusion concept called RemoveBadXSS. It is not a secure solution as it does not analyze the HTML code but simply uses regular expressions to look for malicious HTML.

How was it fixed?

We implemented a sanitizing parser as a separate PHP package called typo3/html-sanitizer. It is a parser based on a allow list instead of a deny list.

The goal of the HTML sanitizer is to remove unwanted HTML code that could lead to cross-site scripting (XSS), a common and serious security vulnerability. Cross-site scripting attacks can exploit other vulnerabilities, allowing an editor to insert potentially malicious HTML code without knowing it. This is why cleaning up the HTML code that is submitted is so important.

We have been looking for a good and powerful solution for more than eight years, but never found a flexible, fast and well-maintained package until now.

We implemented a standard permission list for the HTML Sanitizer and then deployed it in two places:

A: A backend user stores RTE content in the database

Previously we relied on CKEditor's sanitization logic, but this uses client-side validation which cannot always be trusted. This is now cleaned up and moved to the server side. The incoming HTML code is cleaned up each time it is saved. A global setting "rte.htmlSanitize" has been added and activated by default.

B: When rendering HTML content from an RTE field on the website, the so-called parseFunc logic will also call the HTML sanitizer. parseFunc is used to rewrite HTML tags (e.g. TYPO3 internal links to pages), and it is also used in the <f:format.html> ViewHelper.

What are the problems?

1. the HTML sanitizer allowlist contained bugs
Most of the reported issues were related to extended CKEditor plugins or the fact that we had not provided tests for spamProtectedEmailAdresses (which you can and should disable in 2021, as most bots can handle this "obscure" logic). Thanks to the many reports, we were able to fix these issues quickly.

2. people were using parseFunc in places they shouldn't
lib.parseFunc was, in our opinion, a function for parsing RTE content, but people were using <f:format.html> and parseFunc for many other innovative solutions. You can use parseFunc to:

• Replace an HTML tag (e.g. <b> with<em>)
• Add standard CSS classes to all table cell elements
• Add custom tags after each <figure> tag

In fact, lib.parseFunc can be used for any HTML replacement logic, even if there are other solutions, such as TypoScript's replacement option. There are really a thousand ways to solve a single task in TYPO3!

We had several remote sessions with affected users who were struggling with the new behavior. These sessions provided important and helpful insights into use cases and requirements. The following list gives an overview of what has happened so far:

• Troubleshooting and gathering technical details
• Tracking ticket for error reports and corresponding pull requests
• Pull request to relax the sanitization behavior. We urgently need feedback and further testing from the community.

Solutions are in progress - testers are needed

We plan a regression bugfix release (11.3.3, 10.4.20, 9.5.30) as soon as possible, once enough people have reviewed our proposed changes.

We will also ship a new ViewHelper for Fluid: <f:sanitize.html>. It can be used if you just want to make sure that it is safe to re-render user-submitted content.

We realize that only a small group of people can test the security fixes before release, especially in real projects with a lot of custom code. We are actively looking for developers and companies to help us test security changes before they are released. Please contact security(at)typo3.org if you would like to help us test changes before release.

We need contributions for the documentation of best practices, e.g. how to choose the right ViewHelper for a specific situation, and how to better structure and separate data in templates.

Conclusion

We're sorry that the security release caused problems for many of you, but we're also very grateful to everyone who helped with their contributions and feedback. You have made TYPO3 stronger than ever before.

(The original post in English was written by Oliver Hader and Benni Mack with the help of Mathias Bolt Lesniak)

Security message from August 10, 2021 (English)