Vulnerabilidad XSS en el atributo iframe src

Totalmente de acuerdo con @bernesto de hecho, por mucho que intentemos que sea seguro, nunca será suficiente y no quiero dar la impresión de que la biblioteca es "tan segura" como para justificar la falta de validación del servidor. Las opciones actuales (por ejemplo, 'permitirAtraerInseguro', 'permitirValorAtraerInseguro') evitan solo lo básico y común.

Esto es inevitable al usar 'fromElement' para cargar desde un elemento DOM activo. El elemento de la página se carga y ejecuta de forma sincrónica. GrapesJS nunca tendría la oportunidad de procesar y desactivar el HTML de XSS.

Esto tendría que solucionarse impidiendo que el código malicioso se cargue nunca. Esto debería gestionarse en el servidor en la partida guardada. Pero, si en el cliente se necesita procesar, envolviendo el código en etiquetas de script y luego sanitizando el código antes de cargarlo en el editor así:

https://jsfiddle.net/bernesto/5gcxa0jm/1/

Veo que al cargar desde la propiedad 'components' en la inicialización o al publicar dinámicamente desde una fuente remota, existe la misma vulnerabilidad XSS, y esto puede ser algo que queramos evitar.

Personally, creo que el servidor debería procesar todas las partidas guardadas y desinfectar. Un actor malicioso siempre podría emular una solicitud del cliente y guardar un XSS malicioso en tu servidor, independientemente del editor used.

@artf ¿qué opinas?

En tu opinión, ¿debería incorporarse un desinfectante XSS en el editor? Y si es así, eso plantea la pregunta; ¿qué opinas de 'fromElement', por cierto? ¿Debería reimplementarse como algo similar a mi ejemplo, donde el contenido se proporciona usando etiquetas de script en su lugar? Por ejemplo, ¿quizá proporcionar un código fuente (plantilla de script) y un ID de elemento de destino (editor) en su lugar?

Esto no solo nos permitiría desinfectar las vulnerabilidades de XSS, sino que también eliminaría el procesamiento y la pintura de esos elementos iniciales del DOM en el navegador dos veces (una en carga y otra en el nuevo frame). Esto puede acelerar el tiempo de carga del editor como un beneficio positivo.

Gracias por informar de esto, @davidgabrichidze.

Los problemas de seguridad y dependencias son importantes. El equipo de GrapesJS trabaja activamente para mantener las dependencias actualizadas.

Para ti ahora mismo:

1. Ejecutar 'npm audit fix' para ver los parches disponibles
2. Busca una versión más reciente de GrapesJS que ya haya solucionado esto
3. Si está disponible, prueba la última versión estable antes de actualizar
4. Si la vulnerabilidad es crítica, 'npm audit fix ---force' es una opción, pero prueba a fondo

Entendiendo el riesgo:

• Revisar los detalles específicos de vulnerabilidades en los Avisos de Seguridad de GitHub
• No todos los problemas de alta gravedad afectan a tu ruta de código
• Algunas vulnerabilidades solo se activan bajo condiciones específicas

Manteniéndome al día:

• Atentos a nuevos lanzamientos de GrapesJS
• Suscribirse a las notificaciones de seguridad en el repositorio
• El equipo prioriza las actualizaciones de seguridad en su ciclo de lanzamiento