vulnerabilidad de etiqueta IMG

Solía haber una "vulnerabilidad" donde la imagen podía enviar una respuesta HTTP 401 Unauthenticated , lo que activaría una pantalla de inicio de sesión para el usuario. Si lo configura como avatar del foro, generará una ventana emergente de inicio de sesión para cualquier persona que visite una página donde aparezca su avatar. Mucha gente intentará iniciar sesión con una combinación de nombre de usuario y contraseña, probablemente la de su cuenta del foro.

Un amigo mío encontró esto hace unos años, pero hoy en día ya no parece funcionar. Al menos no pude reproducirlo fácilmente hace unos meses. Edición : me equivoqué, este ataque todavía es posible! / edit

En cuanto a los ataques XSS de esta manera, estás a salvo. El navegador, o debería, siempre debe interpretar esto como una imagen sin importar qué contenga o qué encabezados envíe. Puede personalizar la imagen en función de la solicitud (sirve una imagen pequeña para el software del foro que comprueba previamente la imagen para que no la reduzca, por lo que es grande para todos los demás). O alimenta al navegador muchos gif-datos hasta que se agote la memoria o algo así. Pero aquí no hay grandes vulnerabilidades reales que permitan la ejecución remota de código, que yo sepa.

Para lo que solo eres moderadamente seguro son los ataques CSRF. La imagen puede emitir una respuesta HTTP 302 Moved Temporarily y vincular a una nueva ubicación. Por ejemplo, podría enlazar con, no recuerdo la URL específica, algo como https://accounts.google.com/logout y cerrar sesión en google (esto funcionó hace unos meses). O, un poco más maliciosamente: http://example.com/guestbook.php?action=post&message=spam-url.example.com .

Hasta donde sé, solo se pueden hacer solicitudes GET de esta manera. O si la imagen se cargó originalmente como una solicitud POST, supongo que también podría redirigir la POST, pero no cambiar los datos POST. Así que eso es bastante seguro.

Por último, pero no menos importante, si el atacante controla las URL de, por ejemplo, los avatares de los foros (como en los foros de SMF), es posible obtener información de los visitantes, como su dirección IP. Hace un tiempo escribí una herramienta que usaba la página action=who de SMF para vincular las direcciones IP con los nombres de usuario. Cuando comencé a mostrar eso a los usuarios (muestre "Hola $ nombre de usuario con IP: $ IP" en la imagen), todo se desató. "¡¿Cómo puedes saber eso ?!" En su mayoría eran técnicos de la adolescencia temprana, por lo que sabían qué era una dirección IP, pero no sabían que no podía hackearlos. . Sin embargo, se considera información de identificación personal, al menos en los Países Bajos, por lo que los administradores no estaban muy contentos con esta práctica. Sin embargo, si no lo muestra, nadie lo sabrá nunca.

Nota: si esta publicación parece apresuradamente escrita, lo es. Yo apenas estoy despierto también. Tal vez lo limpie mañana si es demasiado narrativo y no menciono suficientes hechos concretos y vulnerabilidades. Espero que esto haya ayudado de todos modos!

La etiqueta IMG intentará interpretar los datos como una imagen, por lo que no se ejecutará Javascript.

Será posible enviar una imagen que, una vez descodificada, requerirá enormes cantidades de memoria ("bomba PNG"), y es posible que las propias rutinas gráficas sean vulnerables a contenido malicioso (una imagen cuidadosamente elaborada que, cuando se decodifica, activa la ejecución de código incrustado). Hubo una vulnerabilidad de este tipo hace casi diez años , y aunque es poco probable, puede aparecer otra. .

ACTUALIZACIÓN : otro lo hizo . Y otro , y este tiene un puntaje de CVSS de 9.3 - " Hay un Compromiso total de la integridad del sistema. Existe una pérdida completa de la protección del sistema, lo que hace que todo el sistema se vea comprometido "

Luego, la etiqueta HTTP_REFERER permitirá al propietario del sitio de la imagen saber qué páginas se han visitado, y mediante el uso de cookies de seguimiento, es posible que se divulgue información (por ejemplo, el sitio malicioso alberga una imagen que se comparte). entre los sitios A, B y C. El propietario de la imagen puede ver que un usuario determinado en el sitio A es la misma persona que otro usuario del sitio B, ya que la imagen establece una cookie cuando se usa en el sitio A, y ahora la misma cookie está llegando de un usuario del sitio B). Dependiendo del escenario, esto podría ser indeseable.

Al incrustar en las partes de la imagen del diseño del sitio host, un atacante podría engañar al usuario para que crea que el sitio aloja un contenido que no está realmente allí. Esto requiere que el HTML / CSS sea vulnerable a un cambio repentino en el tamaño de la imagen. Por ejemplo, un sitio de bolsa de valores puede mostrar, en lugar de una pancarta de 200x80, una pancarta de 200x600 cuyas filas superiores son idénticas a la pancarta original, y la parte de abajo está diseñada para simular el sitio de la bolsa de valores y se "empuja sobre" una acción ticker, y reproduce el mismo ticker de stock, pero con diferentes valores. Un usuario desprevenido puede ser engañado y hacer creer que las cifras de stock son totalmente falsas. Si suficientes usuarios se convencen, esto podría permitir una especie de esquema de "bombear y volcar".

Una variación de esto que a menudo ocurre es cuando vinculas la imagen sin el permiso correspondiente. El propietario del sitio web, que asume el costo de transportar y suministrar la imagen a sus espectadores, tiene la posibilidad de cambiar la imagen con algo completamente diferente . Esto a veces se hace a propósito de antemano, es decir, se siembra una imagen "jugosa" en los foros apropiados (por ejemplo, ¿una combinación contra algún equipo de fútbol?), Luego se cambia con algo con contenido opuesto (lo mismo con los archirrivales de ese equipo) . Para mayor diversión, el webmaster de trolling puede grabar las IP originales que descargaron la imagen y seguir enviando ellas la imagen original. Así que los fanáticos del equipo A publicarán una frambuesa contra el equipo de su propio , y no entenderán por qué todos se ríen: cada vez que ellos miran la imagen, la ven burlándose del equipo B . Lo que sirve como alerta: no asuma que la imagen que ESTÁ viendo es la misma que SUS USUARIOS están viendo .

JavaScript no se ejecutará, incluso si el servidor remoto cambia MIME Content-Type a text/javascript , porque los navegadores pueden esperar ciertos tipos de MIME dentro de la etiqueta IMG . Sin embargo, eso no significa que sean seguros de usar.

Un hilo que sugiero que lea es ¿es seguro permitir que se adjunten imágenes externas al Blog o cualquier contenido web? . Sin embargo, en resumen, los servidores de los que está vinculando imágenes externas aún pueden leer todos los datos de la solicitud HTTP que les envió el navegador del usuario final (es decir, la dirección IP de la solicitud, la cadena de agente de usuario, la versión del protocolo y los datos originales que no son HTTPS). solicite también otros encabezados de solicitud, entre los cuales, referer cadena de URL y, por supuesto, cookies HTTP no seguras).

El servidor remoto también podría generar imágenes dinámicamente, lo que podría crear otras causas de preocupación (contenido inapropiado, temor al agregar información de solicitud de usuario final como la dirección IP, ...), o simplemente rastrear la actividad del usuario en sus servidores mediante la inspección de HTTP solicite los encabezados descritos anteriormente, o eliminando las cookies de seguimiento de terceros con su respuesta. La exposición de la URL en la cadena referer de solicitudes HTTP no seguras a menudo se descuida y puede exponer las direcciones web de su servidor que probablemente no le gustaría que fueran (ubicación del CMS, datos de la sesión de URL, ...) . Lo mismo ocurre con las cookies no seguras que no se limitan a un solo dominio (ubicación) y pueden ser leídas e incluso escritas por un tercero.

Además, el código malintencionado se puede propagar a través de imágenes creadas en sistemas cliente que no fueron parcheadas correctamente. Una de las explotaciones más famosas fue el error de GDI + que podría permitir la ejecución remota de código en versiones anteriores de Windows sin parches. También hay otras vulnerabilidades similares , algunas de las cuales aún no se han abordado correctamente en todos los sistemas .

De algunos de estos ataques recientes, es posible activar código Java (no JavaScript) desde una imagen SVG especialmente diseñada en algunos navegadores ^{[1] [2]} :

  

Exploit-DB - Activación de código Java desde una imagen SVG :

     

SVG es un formato de archivo basado en XML para imágenes estáticas o animadas. Algunos SVG   Las especificaciones (como SVG 1.1 y SVG Tiny 1.2) permiten activar algunos   Código Java cuando se abre el archivo SVG.

y

  

Metasploit - Squiggle 1.7 SVG Browser Java Code Execution :

     

Este módulo abusa del soporte SVG para ejecutar código Java en el   Squiggle Browser incluido en el marco de Batik 1.7 a través de un   Archivo SVG que hace referencia a un archivo jar. Para obtener código arbitrario.   ejecución, el navegador debe cumplir las siguientes condiciones: (1) Debe   admite al menos SVG versión 1.1 o más reciente, (2) Debe admitir Java   el código y (3) la comprobación de "Aplicar guiones seguros" debe estar deshabilitada.   El módulo ha sido probado contra plataformas Windows y Linux

Y un poco más sobre las posibles vulnerabilidades de SVG se puede leer en ¿Explotaciones u otros riesgos de seguridad con la carga de SVG? hilo.

En resumen, no es demasiado seguro y probablemente depende de su confianza en el (los) servidor (es) remoto (s) desde el que estaría vinculando las imágenes para no explotar eso.

Sí, estás a salvo.

Por supuesto, la página que recibe cuando hace clic derecho > Ver imagen puede ser malicioso, pero no se ejecutará ningún script en el contexto de su sitio web.

Además, no olvide que el propietario del sitio web de la imagen puede rastrear a sus visitantes en todas las páginas donde está incrustada la imagen.

Una solicitud IMG es una solicitud GET a un servidor arbitrario, que puede no ser segura

La respuesta del servidor puede eliminar o sobrescribir las cookies que pueden afectar el funcionamiento de su navegador.

Más información

Stackoverflow fue una vez mordido por este error, donde se podía acceder a la API REST de cierre de sesión mediante una simple solicitud GET.

Creo que el escenario fue así:

1. Un spammer publicó spam en una página determinada.
2. En esa página, incluyeron una obtención para /users/logout en una etiqueta IMG
3. Las cookies de autenticación para el usuario se eliminaron a través de los encabezados HTTP.
4. Cada vez que un administrador o moderador intentara eliminar el SPAM se cerró la sesión.

Esto es parte de la razón por la que hay una página de cierre de sesión cuando haces clic en "cerrar sesión" en SO.

Aparte: aunque SO es un sitio HTTP (no "s" / SSL), creo que las cookies seguras serían vulnerables