¿Explotaciones u otros riesgos de seguridad con la carga de SVG?

  

Podría construirse un SVG de tal manera, que al leer metadatos hace que el servidor no responda. y podría ser utilizado como ataque DoS en el servidor?

¿Qué quieres decir con metadatos? Si buscas ancho y alto, deberías analizar los archivos SVG al menos parcialmente para obtenerlo; no hay un atajo para leer algunos bytes del encabezado, como ocurre con muchos formatos de mapa de bits. Esto trae los riesgos habituales del análisis XML, como:

• Ataques de inclusión de entidad externa / subconjunto DTD contra archivos remotos, recursos sensibles a la red local, archivos sensibles a la máquina local y archivos de dispositivo
• bombas de expansión de entidades anidadas
• las estructuras de etiquetas anidadas patológicamente podrían afectar los límites de recursos de recursión

como precaución estándar, deshabilitaría todo el procesamiento de DTD, XInclude, XSL, XSI y la resolución de entidades.

  

¿Se podría construir un SVG de tal manera que, al representar el SVG en el cliente, el cliente deje de responder y potencialmente haga que todos los usuarios del navegador de mi sitio se bloqueen?

Posiblemente, pero es posible que ocurra con un formato de mapa de bits. Ver, por ejemplo, las vulnerabilidades de archivos PNG corruptos de hace un tiempo.

Más preocupante para los archivos SVG es que pueden incluir JavaScript, que funcionará en el contexto de seguridad del sitio de hospedaje, por lo que debe preocuparse por los scripts entre sitios.

En realidad, todos los tipos de archivos cargados son vulnerables a esto, aunque no de una forma tan directa y fácil de explotar. En algunos casos, los navegadores (particularmente IE) los rastrearán, y si ven cosas que parecen etiquetas, posiblemente los reinterpretarán como HTML, incluido JavaScript. También hay algunos problemas secundarios con el tratamiento de los archivos cargados como applets de Java y archivos de políticas de Flash.

La mitigación estándar para todos estos problemas es servir sus recursos no confiables, ya sea mapa de bits, SVG o cualquier otra cosa, desde un dominio diferente a su sitio principal: un dominio que no tiene información sensible de sesión (cookie / autenticación) en él. y no hay capacidad para realizar scripts en el dominio de su sitio principal.

  

Además, ¿sería una buena práctica generar un pequeño PNG (200x200px) para una miniatura, o es mejor simplemente manipular el SVG con un factor de zoom o algo así?

Eso sería un buen toque, pero tendrías que arrastrar algunas dependencias para renderizar en mapa de bits, por ejemplo, Batik si estás usando Java. Naturalmente, traer una nueva biblioteca compleja aumenta la superficie de ataque; Podría ser una buena idea ejecutar el miniaturas como una tarea separada del daemon de baja prioridad de cuenta de privilegios bajos.

Cualquier acción que realice su aplicación web es potencialmente peligrosa. La carga de archivos es una de las características más peligrosas porque puede llevar a la ejecución remota de código.

El problema con la carga de cualquier archivo al servidor es que podría no ser el archivo que desea. No sé qué plataforma o metodología está utilizando, pero he engañado a los sistemas de carga de archivos muchas veces para cargar un archivo .php o .asp y ejecutarlo. No suena como si estuvieras renderizando el SVG en el lado del servidor (eso sería algo extraño de todos modos), por lo que el XML sin procesar en el SVG realmente no importa para tu servidor.

En términos de # 2, sí las vulnerabilidades de corrupción de memoria svg son comunes y yo Estoy seguro de que existen más. Pero nuevamente, esto será cierto para casi cualquier archivo que cargue. Las imágenes SVG son un poco más nuevas y la mayor parte de las vulnerabilidades en las imágenes SVG se encontraron en 2011.

SVG enmascaramiento se utiliza para marcos flotantes oscuros en un ataque de clickjacking . Pero no creo que este vector de ataque se aplique a su sistema de carga svg.