La mayoría de los WAF cuando bloquean XSS bloquearán etiquetas obvias como script y iframe , pero no bloquean img .
Teóricamente, puedes img src='OFFSITE URL' , pero ¿qué es lo peor que puede pasar? Sé que puedes robar IPs con él, pero ¿es eso?
Al igual que Anders dice: Blender hace un muy buen punto acerca de los diálogos de autenticación, y korockinout13 es justo acerca de los atributos on. Además, Aders agrega argumentos sobre la etiqueta a y Matija tiene un buen enlace sobre la explotación de bibliotecas que realizan el representación.
Sin embargo, nadie ha hablado de SVG todavía.
En primer lugar, supongamos que todas las entradas y salidas están correctamente saneadas, por lo que los trucos con onerror / onload no son posibles. Y que no estamos interesados en CSRF. Estamos tras XSS.
La primera preocupación sobre <img src= es que no sigue la misma política de origen. Pero eso es probablemente menos peligroso de lo que parece.
< img src="http://domain/image.png">esbastanteseguroporqueelnavegadornoinvocaráunanalizador(porejemplo,unanalizadorXMLoHTML),sabequeloquevendráesunaimagen(gif,jpeg,png).
ElnavegadorrealizarálasolicitudHTTPysimplementeleeráelMIMEdeloquevino(enelencabezadoConetent-Type,porejemplo,image/png).SilarespuestanotieneunContent-Type,variosnavegadoresadivinaránsegúnlaextensión,perosoloadivinaránlosMIMEdeimagen:image/jpeg,image/pngoimage/gif(tiff,bmpyppmsondudosos,algunosnavegadorespuedentenerunsoportelimitadoparaadivinarlos).Algunosnavegadorespuedeninclusointentaradivinarelformatodelaimagenbasándoseennúmerosmágicos,perotampocointentaránadivinarlosformatosesotéricos.
SielnavegadorpuedecoincidirconelMIME(posiblementeadivinado),cargalabibliotecaderepresentacióncorrecta,lasbibliotecasderepresentaciónpuedentenerundesbordamiento,peroesaesotrahistoria.SielMIMEnocoincideconunabibliotecaderepresentacióndeimágenes,laimagensedescarta.Silallamadadelabibliotecaderenderizadofalla,laimagentambiénsedescarta.
Elnavegadornuncaestánisiquieracercadeuncontextodeejecución(script).Lamayoríadelosnavegadoresingresanenelcontextodeejecuciónsolodesdeelanalizadordejavascript,ysolopuedenalcanzarelanalizadordejavascriptdesdeelapplication/javascriptMIMEodesdelosanalizadoresdeXMLoHTML(yaquepuedentenerscriptsincrustados).
PararealizarXSSnecesitamosuncontextodeejecución.EntraenSVG.
Auch, ay, ay. SVG es un formato de gráfico vectorial basado en XML, por lo que invoca el analizador XML en el navegador. Además, SVG tiene la etiqueta <script> ! Sí, puedes incrustar javascript directamente en SVG.
Esto no es tan peligroso como parece al principio. Los navegadores que admiten SVG en las etiquetas <img> no admiten las secuencias de comandos en el contexto . Lo ideal sería utilizar SVG dentro de las etiquetas <embed> o <object> donde los navegadores admiten las secuencias de comandos. Sin embargo, ¡no lo hagas por el contenido proporcionado por el usuario!
Argumentaría que permitir SVG dentro de <img src= puede ser peligroso:
Se usa un analizador XML para analizar el SVG, ya sea que esté dentro de la etiqueta <img> o <object> . El analizador ciertamente está ajustado con algunos parámetros para ignorar las etiquetas <script> en el contexto <img> . Sin embargo, eso es bastante feo, es poner una etiqueta en una lista negra en un contexto determinado. Y las listas negras son una seguridad deficiente.
<script> no es la única forma de lograr un contexto de ejecución en SVG, también hay los eventos onmouseover (y familia) presentes en SVG. Esto es nuevamente difícil de poner en la lista negra.
El analizador XML en los navegadores sufrió problemas en el pasado, notables con los comentarios XML en torno a los bloques de script. SVG puede presentar problemas similares.
SVG tiene soporte completo para espacios de nombres XML. Ay otra vez. xlink:href es una construcción completamente válida en SVG y el navegador dentro del contexto del analizador XML probablemente lo seguirá.
Por lo tanto, sí, SVG abre varios vectores posibles para lograr un contexto de ejecución. Y, además, es una tecnología relativamente nueva y, por lo tanto, no está bien endurecida. No me sorprendería ver CVEs en el manejo de SVG. Por ejemplo, ImageMagick tuvo problemas con SVG .
Firefox (corregido en Nightly 59.0a1), Safari (corregido en Safari Technology Preview 54), Edge e Internet Explorer muestran un cuadro de diálogo de autenticación si solicita una imagen y el servidor le pide que se autentique con la autenticación básica de HTTP. Esto permite a un atacante mostrar un cuadro de diálogo de autenticación cuando el navegador de un usuario intenta cargar la imagen:
Firefox . Se corrigió a partir de Nightly 59.0a1, pero la advertencia está presente en la última versión estable:
De acuerdo, ¿qué te parece esto? (probablemente deberías retroceder)
<img src="file://uhoh.gif”>
Oh, lo sé, ¿verdad? ¡Qué monstruo!
Bien podría ser, si está utilizando SMB ...
¡Es un error que ha existido durante 18 AÑOS! Consulte este informe de vulnerabilidad de 1997. Aquí encontrará la misma vulnerabilidad en BlackHat, en 2015 .
Esto afecta a Internet Explorer, incluido Microsoft Edge. Cabe señalar que esto no afecta a los navegadores Chrome o Mozilla. IE intenta autenticarse automáticamente en el sitio web del atacante, pasar el nombre de usuario y la contraseña NTLM al servidor remoto, y sí, incluso a través de Internet (!!).
Por lo tanto, concluyo que absolutamente nadie debería usar una etiqueta IMG, nunca.
Sí, pero es XSS? No, no necesariamente lanza o no constituye un ataque XSS, que yo sepa. Aunque puede ser lanzado desde uno, no es un requisito. ¿Cuenta la red?
Creo que con "img XSS" quiere decir "sitio que permite valores arbitrarios para el atributo src="" de los elementos <img /> ".
... en cuyo caso, el riesgo principal es la falsificación de solicitudes entre sitios (CSRF, por sus siglas en inglés), ya que significa que un atacante puede hacer que un objetivo realice una solicitud arbitraria de GET , el ejemplo canónico es el "sitio web del banco mal codificado". transferencias de dinero utilizando GET pedidos "-vulnerability.
Sin embargo, no necesariamente tiene que ser una solicitud de falsificación de sitio cruzado : me imagino que el tipo principal de sitio que permite los elementos <img /> proporcionados por el usuario es un foro web y los foros tienden a tener paneles de control de administrador en el mismo sitio web, por lo que si se pueden invocar acciones "útiles" de administrador o moderador a través de GET, entonces esa es otra posibilidad, pero esto aún está bajo el paraguas CSRF.
La respuesta de la D señala que se puede usar GET para emitir comandos tanto cruzado sitio y en el mismo sitio. Quiero ampliar esa noción porque decir "Es una solicitud GET ; tenga cuidado" no suele transmitir el por qué que podría ser un problema.
Un ataque que se puede hacer y que otras respuestas no han cubierto es la denegación de servicio. Considera lo siguiente:
Estás en un foro y alguien publica un mensaje que tiene un <img src="/logout" /> incrustado. Esto hace que todos se desconecten cuando se carga la imagen. Ahora, ninguno de los usuarios puede usar el foro, siempre que vea esa página.
Este es un ejemplo relativamente trivial, pero no obstante es un problema potencial. Para mostrar cómo podría ser un problema mayor, imagine que es un tipo de sitio de noticias u otro que muestra los comentarios de los usuarios en la página principal y luego de iniciar sesión, se le redirige allí. Ahora nadie puede iniciar sesión sin cerrar sesión inmediatamente.
Hasta ahora, estos no son ataques entre sitios. Sin embargo, pueden convertirse relativamente simplemente en eso. Imagínese si Facebook u otro sitio web popular permite una fuente arbitraria de imágenes y usted publica el siguiente <img src="http://yourdomain.com/logout"/>:lagentesedesconectarásinsiquieratenerqueestarenyourdomain.com.Estopuedeirdesdemolesto("Ugh, el sitio web solicita mi contraseña otra vez ") a potencialmente problemático ("Espera, ¿a dónde se fue todo mi trabajo no guardado?").
Es totalmente posible que ni siquiera se cierre la sesión cuando la imagen apunta. ¿Qué pasa si es http://yourdomain.com/deleteMyUser lo que hace que los usuarios "abandonen" el sitio web sin su consentimiento? ¿O quizás el http://yourdomain.com/findPrimes?count=9001 más plausible que eventualmente sobrecargará su servidor para hacer cálculos pesados?
Lo que más me molesta de este tipo de ataque es que ni siquiera es un problema con las etiquetas img , incluso si tu webapp es cuidadosa con las imágenes, es posible que otra persona no lo sea. El núcleo del problema es que el enlace de cierre de sesión (o cualquier recurso que pueda explotar un atacante) solo puede invocarse a través de GET y la imagen es simplemente vectorial para que los navegadores emitan ese GET . El problema es que no es del todo obvio para muchos desarrolladores ese es el caso.
Además de todas las demás respuestas ya mencionadas, la imagen en sí misma puede modificarse deliberadamente de tal manera que al analizarla explota la máquina del usuario y, por lo tanto, permitir la ejecución remota de código, consulte ¿Puede simplemente descomprimir una imagen JPEG para activar un exploit?
Blender hace un muy buen punto sobre los diálogos de autenticación, y korockinout13 tiene razón sobre los atributos on . Sin embargo, tengo una adición.
En algunas situaciones, puede utilizar el control de imágenes para cambiar el diseño de la página y falsificar partes de la página. No es muy poderoso ya que no puedo hacer nada dinámico, pero a veces se puede usar de manera inteligente.
Por ejemplo, si puedo insertar una etiqueta img en la página de resultados de búsqueda al buscar una, podría incluir una imagen con resultados de búsqueda falsos. De esa manera podría hacer que se vea como una búsqueda de "OVNI" en las noticias locales que devuelve historias sobre el gran aterrizaje alienígena de 2016.
Si la vulnerabilidad está dentro de una etiqueta a que realiza una acción, podría insertar una imagen que imite otras partes de la página. De esa manera, cuando el usuario hace clic en "Aceptar", en realidad está haciendo clic en mi imagen que contiene una descripción de un botón falso "Aceptar", pero en realidad forma parte del enlace "Eliminar".
Si puedo crear mis propios enlaces con imágenes en ellos, esto se pone aún mejor ...
Como dije, no es el hack más poderoso del mundo, pero sí lo suficiente como para no permitir que las imágenes no sean necesarias.
puede usarse para inyectar cualquier JavaScript arbitrario. De hecho, cualquier etiqueta HTML combinada con cualquier atributo de evento "on" (por ejemplo, onerror, onclick, uponuchstart, etc.) se puede usar para ejecutar cargas de JavaScript sin restricciones.