Algunas respuestas mencionan que es posible a inyectar HTML controlado por el atacante en las imágenes y, por lo tanto, provocar XSS.
Supongo que este HTML solo será procesado por el navegador si existe un agujero en el navegador. Así que creo que es más un problema del navegador y no es necesario convertir esas imágenes, eliminar los metadatos EXIF, aleatorizarlos en el lado de la aplicación web.
¿El atacante puede inyectar HTML en la imagen que provocará XSS? Si es así, ¿cómo?
Estoy bastante seguro de que bstpierre hablaba de una situación en la que permites que los usuarios suban imágenes para mostrarlas Una galería y, además, muestra metadatos sobre esa imagen tomada de las etiquetas EXIF. Si las etiquetas EXIF se construyeron específicamente con etiquetas html maliciosas y no hubo un saneamiento de entrada (por ejemplo, los caracteres de escape como < , > , & , por lo que se representan en la página como < > , & ) posiblemente podrías usarlos para un ataque XSS. Nuevamente, no es un problema si su aplicación web desinfecta todas las entradas del usuario, incluidas las etiquetas extraídas de los archivos de imagen.
Bobince hablaba de algunas cosas totalmente diferentes; Lo más cercano es que alguien carga un archivo, por ejemplo, fake_image.jpg, pero en lugar de ser una imagen, el contenido es en realidad un archivo html. Al rastrear el contenido, quiso decir que algunos navegadores, al hacer clic para abrir una página enlace , pueden descubrir que fake_image.jpg no es una imagen pero en su lugar un archivo html y mostrará la página html en el archivo. Por lo tanto, el archivo html cargado (con un nombre de archivo de imagen) podría usarse en un ataque XSS. Para que este ataque sea útil, debe tener un navegador que permita este tipo de rastreo de contenido, y luego debe ir a la URL de la imagen (no solo tener <img src='fake_image.jpg'> incrustado en la página).
Lamentablemente, has adivinado mal. Estos ataques son posibles, sin un error de navegador; explotan una falla de diseño en muchos navegadores anteriores. Querrá leer sobre los ataques de rastreo del tipo de contenido MIME y los ataques relacionados. Hay mucho que se ha escrito sobre esto:
Un SVG en línea en HTML puede contener controladores de eventos y nodos de script SVG. Entonces, si puedo especificar una imagen SVG para que se cargue tu página y hacer que la inscribas en la página, puedo inyectar el script a través de esa imagen.
El elemento
svgdel espacio de nombres SVG cae en las categorías de contenido incrustado, contenido de frases y contenido de flujo para los propósitos de los modelos de contenido en esta especificación....
La semántica de los elementos SVG está definida por la especificación SVG y otras especificaciones aplicables. [SVG]
Mario Heiderich explotó la confusión en Opera acerca de qué dominio SVG contenido debe ejecutar para crear un imagen que cuando se carga entre dominios, ataca varias capas y termina llamando a su teléfono.
Resumen
- Los SVG no son solo imágenes, sino mini aplicaciones
Las etiquetas- ahora pueden implementar Java, PDF y Flash, y te llaman en Skype
- SVG en línea crea pequeñas islas XML que permiten los ataques XML en Sitios web HTML
- SVG y XSLT también funcionan, habilitando DoS y otros ataques
- Seguridad web y seguridad XML, ¡se vuelven a encontrar!
- Y XXE está de vuelta, ¿recuerdas las advertencias de 2002?
- SVG no está recibiendo suficiente atención en la seguridad comunidad
- SVG ofrece mucho espacio para más investigación de seguridad
En diapositivas anteriores, Mario analiza XSS específicamente y los problemas con la descarga de archivos SVG para ejecutarse localmente y notas
- Permitiendo SVG para subir == permitiendo HTML para subir
Es posible escribir políglotas: archivos que son válidos en varios idiomas, como un archivo que es una página HTML y una imagen JPEG GIF y un programa de JavaScript . Esa segunda página explica:
la imagen de arriba es un archivo GIF perfectamente válido, al igual que un programa javascript perfectamente válido (de hecho, ¡incluso es un programa de Caja válido!). Una etiqueta de imagen espera que su atributo src apunte al contenido que se analiza correctamente como una imagen, al igual que una etiqueta de script espera que su atributo src apunte a un archivo javascript. La etiqueta especifica un contexto en el que se espera el contenido de un tipo particular. Si la única información que un navegador utilizaba para representar contenido era el contexto creado por la etiqueta circundante, las cosas serían simples. Pero las cosas en el mundo del navegador nunca son simples. Cuando un servidor envía un archivo, también envía el tipo MIME de ese archivo en un encabezado de tipo de contenido. Todo está bien cuando el tipo de contenido que el servidor afirma es consistente con el contexto esperado en el que se usa ese contenido. ¿Qué sucede cuando el servidor no envía un tipo de contenido? ¿Qué sucede cuando se envía un archivo con un tipo de contenido cuando se espera un tipo diferente?
...
Los navegadores realizan un rastreo de contenido aparentemente en interés de la facilidad de uso, por lo que incluso los servidores mal configurados pueden continuar "trabajando". El problema aquí es que un navegador da diferentes tipos de contenido diferentes cantidades de acceso. Si puede engañar al navegador para que piense que un tipo de contenido es realmente otro, puede pasar por alto las restricciones impuestas al acceso al contenido real. Por ejemplo, una página HTML puede cargar imágenes externas, hojas de estilo y scripts. En este caso, el contexto de seguridad en el que se ejecutan estos recursos se deriva de la URL de la página en la que están incrustados. Por otra parte, si el tipo de contenido que se está cargando es Flash o Java, por ejemplo, el contexto de seguridad se deriva de La URL del propio applet. Si el navegador utiliza heurísticas y se confunde entre un objeto Flash y una imagen, ¡existen implicaciones reales para la seguridad! Este tipo de confusión fue la fuente del ataque GIFAR.
Lea otras preguntas en las etiquetas web-application exploit xss file-upload
