Información sobre la actualización de seguridad de TYPO3 del 10 de agosto de 2021 (actualización)

Por regla general, las versiones de TYPO3 alojadas por nosotros se actualizan automáticamente. Nuestros clientes no tienen que preocuparse de los detalles técnicos.

Las actualizaciones de seguridad se realizan en 24 horas, mientras que nosotros esperamos unos días para las actualizaciones periódicas.

¿Por qué esperar? Bueno, a veces ocurre que una actualización puede provocar efectos no deseados en algunas instalaciones. Las nuevas versiones son probadas por el equipo de desarrollo de TYPO3 y por nosotros antes de ser instaladas para nuestros clientes. Sin embargo, como los sitios web están configurados de forma muy diferente y a menudo tienen extensiones individuales, no todas las variaciones pueden ser cubiertas por las pruebas.

Para las actualizaciones normales con correcciones de errores, por lo tanto, esperamos unos días y supervisamos el rastreador de errores TYPO3, foros, Slack y canales de medios sociales. Solo cuando no se informa allí de ningún incidente, distribuimos las nuevas versiones a nuestros clientes.

Con la actualización de seguridad del 10 de agosto, sin embargo, hubo algunos informes de incompatibilidades, por lo que aún no hemos desplegado las nuevas versiones. Por lo tanto, esperamos a que se publiquen nuevas actualizaciones dentro de unos días. Todos los clientes tienen siempre la posibilidad de instalar ellos mismos una actualización. Actualización: Entretanto se han publicado las versiones de TYPO3 10.4.20, 9.5.30, 8.7.43 y 7.6.54. Estas deberían resolver los problemas notificados. Estas deberían resolver los problemas reportados.

He aquí una traducción de un artículo publicado en typo3.org el 14 de agosto:

Las versiones de seguridad publicadas el martes 12 de agosto de 2021 contienen una corrección de errores muy importante. Elimina el código HTML malicioso e incorrecto de los campos habilitados para texto enriquecido. Sin embargo, también ha causado problemas a varios sitios web.

En el TYPO3 Core Team y en el Security Team nos alegramos de que la versión ofreciera por fin una solución segura a este problema grave y antiguo. Pero, ¿quizás era demasiado segura? Pronto nos contactaron personas de la comunidad TYPO3 que nos hablaron de situaciones en las que el desinfectante estaba desinfectando demasiado o en los lugares equivocados.

En este artículo, nos fijamos en lo que la versión de seguridad corrige, lo que causa los problemas y cómo resolverlos.

¿Qué es un campo de texto enriquecido?

Un campo habilitado para texto enriquecido, también conocido como contenido RTE, es un campo en el que los editores pueden insertar formato, enlaces, tablas, etc. Probablemente lo reconocerá como el campo de texto más destacado de los elementos Texto o Texto con contenido multimedia. El editor de texto enriquecido utiliza código HTML, y sin desinfección sería posible utilizarlo para insertar código malicioso en una página.

¿Cuál era el problema de seguridad?

Los campos habilitados para texto enriquecido formatean el texto con código HTML, y sin higienización sería posible utilizarlo para inyectar código malicioso en una página. Esto es similar a otros tipos de contenido personalizado, como los campos de los formularios de comentarios, en los que la información introducida se vuelve a previsualizar antes de enviar el correo electrónico y se almacena en la base de datos.

Antes de la versión de seguridad, TYPO3 utilizaba un concepto de exclusión llamado RemoveBadXSS. No es una solución segura, ya que no analiza el código HTML, sino que simplemente utiliza expresiones regulares para buscar HTML malicioso.

¿Cómo se ha solucionado?

Hemos implementado un parser de sanitización como un paquete PHP separado llamado typo3/html-sanitizer. Es un analizador basado en una lista de permitidos en lugar de una lista de denegados.

El objetivo del sanitizador HTML es eliminar el código HTML no deseado que podría conducir a cross-site scripting (XSS), una vulnerabilidad de seguridad común y grave. Los ataques de cross-site scripting pueden explotar otras vulnerabilidades, permitiendo a un editor insertar código HTML potencialmente malicioso sin darse cuenta. Por eso es tan importante desinfectar el código HTML enviado.

Llevamos más de ocho años buscando una solución buena y potente, pero hasta ahora no habíamos encontrado un paquete flexible, rápido y bien mantenido.

Implementamos una lista de permisos estándar para el HTML Sanitizer y luego lo desplegamos en dos lugares:

A: Un usuario backend almacena el contenido RTE en la base de datos.

Anteriormente nos basamos en la lógica de sanitización de CKEditor, pero esto utiliza la validación del lado del cliente que no siempre se puede confiar. Ahora esto se ha limpiado y trasladado al lado del servidor. El código HTML entrante se limpia cada vez que se guarda. Se ha añadido un ajuste global "rte.htmlSanitize" que se activa por defecto.

B: Al renderizar el contenido HTML de un campo RTE en el sitio web, la llamada lógica parseFunc también llamará al sanitizador HTML. parseFunc se utiliza para reescribir etiquetas HTML (por ejemplo, enlaces internos TYPO3 a páginas), y también se utiliza en el ViewHelper <f:format.html>.

¿Cuáles son los problemas?

1. El HTML sanitizer allowlist contenía errores La mayoría de los problemas reportados estaban relacionados con plugins extendidos de CKEditor o con el hecho de que no habíamos proporcionado pruebas para spamProtectedEmailAdresses (que puede y debe desactivar en 2021, ya que la mayoría de los bots pueden manejar esta lógica "oscura"). Gracias a los numerosos informes, pudimos solucionar estos problemas rápidamente.

2. la gente estaba usando parseFunc en lugares donde no debería lib.parseFunc era, en nuestra opinión, una función para analizar contenido RTE, pero la gente estaba usando <f:format.html> y parseFunc para muchas otras soluciones innovadoras. Puede utilizar parseFunc para:

• Sustituir una etiqueta HTML (por ejemplo, <b> por<em>)
• Añadir clases CSS estándar a todos los elementos de celda de tabla
• Añadir etiquetas personalizadas después de cada etiqueta <figure>.

De hecho, lib.parseFunc puede utilizarse para cualquier lógica de sustitución de HTML, incluso si existen otras soluciones, como la opción de sustitución de TypoScript. ¡Realmente hay mil maneras de resolver una sola tarea en TYPO3!

Tuvimos varias sesiones remotas con usuarios afectados que estaban luchando con el nuevo comportamiento. Estas sesiones proporcionaron información importante y útil sobre los casos de uso y los requisitos. La siguiente lista ofrece una visión general de lo que ha sucedido hasta ahora:

• Resolución de problemas y recopilación de detalles técnicos
• Ticket de seguimiento de informes de error y pull requests correspondientes
• Pull request para relajar el comportamiento de saneamiento. Necesitamos urgentemente comentarios y más pruebas de la comunidad.

Las soluciones están en curso - se necesitan probadores

Estamos planeando una versión de corrección de errores de regresión (11.3.3, 10.4.20, 9.5.30) tan pronto como sea posible, una vez que suficientes personas hayan revisado nuestros cambios propuestos.

También enviaremos un nuevo ViewHelper para Fluid: <f:sanitise.html>. Se puede utilizar si sólo desea asegurarse de que es seguro volver a renderizar el contenido enviado por el usuario.

Somos conscientes de que sólo un pequeño grupo de personas puede probar las correcciones de seguridad antes del lanzamiento, especialmente en proyectos reales con mucho código personalizado. Buscamos desarrolladores y empresas que nos ayuden a probar los cambios de seguridad antes de su publicación. Ponte en contacto con security(at)typo3.org si quieres ayudarnos a probar los cambios antes de su publicación.

Necesitamos contribuciones para la documentación de las mejores prácticas, por ejemplo, cómo elegir el ViewHelper adecuado para una situación específica, y cómo estructurar y separar mejor los datos en las plantillas.

Conclusión

Lamentamos que la versión de seguridad haya causado problemas a muchos de ustedes, pero también estamos muy agradecidos a todos los que ayudaron con sus contribuciones y comentarios. Usted ha hecho TYPO3 más fuerte que nunca.

(El post original en inglés fue escrito por Oliver Hader y Benni Mack con la ayuda de Mathias Bolt Lesniak)

Mensaje de seguridad del 10 de agosto de 2021 (Inglés)