About the Latest TYPO3 Core Security Release

Rich-text-enabled fields format text using HTML code, and without sanitation it would be possible to use it to insert malicious code on a page. This is similar to other kinds of User-Submitted Content, such as fields in feedback forms, where the submitted information is displayed again as a preview before sending out the email and storing it into the database.

Prior to the security release, TYPO3 used a deny list concept called RemoveBadXSS. It is not a safe solution because it didn’t parse the HTML, but simply used regular expressions to search for malicious HTML.

We implemented a sanitizing parser as a separate PHP package called typo3/html-sanitizer. It is a parser based on an 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 make use of other security holes, so an editor can potentially add malicious HTML code, even without knowing it. This is why sanitizing submitted HTML is so important.

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

We implemented a default allow list for the HTML Sanitizer and then put it to use in two places:

• When a backend user saves RTE content to the database. We used to rely on CKEditor's sanitization logic, but it is using client-side validation that cannot always be trusted. This is now cleaned up and moved to the server side. On every save the incoming HTML is sanitized. A global feature flag “rte.htmlSanitize” was added and enabled by default.

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

1. The Allow List of the HTML Sanitizer Contained Bugs

Most of the issues reported were related to extended CKEditor plugins, or the fact that we did not consider having tests for spamProtectEmailAddresses (which you can and should disable in 2021, as most bots can deal with this "obscure" logic). Thanks to all the reports, we could quickly resolve these.

2. People Used parseFunc in places where they shouldn't

lib.parseFunc was in our opinion a feature to parse RTE content, but people used <f:format.html> and parseFunc for a lot of other innovative solutions. You can use parseFunc to:

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

In fact, lib.parseFunc can be used for any HTML-replacing logic, even though we have other solutions, such as TypoScript’s replacement option. There are truly a thousand ways to solve a single thing in TYPO3!

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

• Troubleshooting & technical details collection
• Tracking ticket for bug reports and corresponding pull-requests
• Pull-request to relax the sanitization behavior. We really need feedback & more tests by the community.

We are planning 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 people just want to make sure that it is safe to re-render user-submitted content.

We are aware that only a small group of people can test the security bug fixes before the release, especially in real-life projects with lots of custom setup code. We are actively looking for developers and companies, willing to help us test security changes before they are released. Please reach out to security(at)typo3.org if you would like to help us test changes before they are released.

We need contributions to write documentation on best practices, for example how to choose the right ViewHelper for a given situation, and how to structure and separate data in templates in a better way.

We are sorry for the trouble the security release caused for many of you, but we're also very grateful to everybody who helped by contributing and providing feedback. You have made TYPO3 stronger than ever.