Este artículo del blog de muffin.ink explora una serie de vulnerabilidades de seguridad que han afectado a Scratch, una plataforma de programación visual para niños, debido a la forma en que maneja los archivos SVG (Scalable Vector Graphics). El problema central radica en que Scratch analiza contenido SVG generado por el usuario (potencialmente malicioso) e lo integra en el documento principal para diversas operaciones, como medir el tamaño. Esta práctica, por sí sola, es inherentemente insegura.
La historia de la seguridad de SVG en Scratch es un ciclo repetitivo de descubrimiento de vulnerabilidades, aplicación de parches y, eventualmente, descubrimiento de nuevas formas de eludir esos parches. En 2019, se encontró una vulnerabilidad de XSS (Cross-Site Scripting) permitiendo la ejecución de scripts maliciosos incrustados en etiquetas <script> dentro del SVG. La solución inicial fue eliminar estas etiquetas con una expresión regular, pero esta fue rápidamente burlada en 2020 mediante el uso de mayúsculas en la etiqueta <SCRIPT>. Posteriormente, se implementó DOMPurify, una biblioteca de sanitización, para eliminar scripts, pero esto no impidió nuevas amenazas.
En 2022, se descubrió una vulnerabilidad de fuga de HTTP a través del atributo href en elementos <image>, permitiendo a los atacantes realizar solicitudes externas sin interacción del usuario. En 2023, se encontró otra fuga de HTTP a través de la declaración CSS @import. La solución fue integrar un parser CSS para eliminar estas declaraciones. La vulnerabilidad más reciente, en 2024, surgió debido a que los SVGs no sanitizados se pasaban a la biblioteca Paper.js, utilizada en el editor de disfraces, lo que permitía una nueva XSS. Finalmente, en 2025, se descubrió una nueva fuga de HTTP a través de la función url() en CSS, requiriendo una expansión significativa del código de sanitización.
El artículo concluye que el enfoque de Scratch para la sanitización de SVG es fundamentalmente problemático, ya que cada solución genera nuevas formas de eludirla. La complejidad de la sanitización de SVG es considerable, y la confianza en que un conjunto de reglas puede cubrir todas las posibles técnicas de ataque es infundada. La situación subraya la dificultad de asegurar sistemas que procesan contenido generado por el usuario y la necesidad de un enfoque más fundamental para evitar la integración de contenido potencialmente peligroso en el documento principal.