vectores XSS en img src y url de imagen de fondo

Navega tus respuestas
2

Estoy un poco confundido acerca de las vulnerabilidades de XSS al servir img.src y url de fondo. Por lo que entiendo, la única forma de ejecutar javascript en este caso, es usar el protocolo javascript. Consideremos este ejemplo: 

if (location.hash.indexOf('javascript:') !== 0) {
    img.style.backgroundImage='url("'+location.hash+'")';
 }
 img.src='some/local/path/'+location.hash;

¿Existe una vulnerabilidad XSS en este código?

    
pregunta Maciej Krawczyk 01.06.2016 - 20:33
fuente

2 respuestas

4

No , en los navegadores modernos no es posible XSS a través del atributo style o src de una etiqueta <img> .

Por lo tanto, ninguno de estos ejecutaría el código JS en ningún navegador actualizado: 

<img src="javascript:alert(1)">
<img src="x.jpg" style=background-image:url('javascript:alert(2)')">

El soporte para Javascript en los atributos CSS tiene Ha sido abandonado hace mucho tiempo . Puede encontrar algunas referencias anteriores al respecto aquí .

Análisis de su código de ejemplo

location.hash siempre comienza con un símbolo # . Dado que este carácter es ilegal en JS y no es un inicio válido de una nueva URL, ningún XSS sería posible en primer lugar. (Por ejemplo, eval(location.hash) siempre produce un error de sintaxis).

Supongamos que ignora que # y location.hash realmente podrían contener cualquier cadena que desee.

Entonces este control de seguridad es defectuoso: 

(location.hash.indexOf('javascript:') !== 0)

Un atacante aún podría construir una URL que comience con JaVaScRiPt: . Además, es arriesgado suponer que ninguna implementación permitiría nunca espacios iniciales o caracteres de control (por ejemplo, \t\x00javascript: ). ¿Y qué pasa con la codificación de URL? Una carga útil que comienza con javascript%3a pasaría su filtro. Además, ¿quieres permitir el protocolo data: ? Si desea restringir la URL a ubicaciones absolutas, puede agregar a la lista blanca los inicios http:// y https:// en lugar de poner en la lista negra javascript: .

Esto está bien: 

img.src='some/local/path/'+location.hash;

Incluso si el atributo src era susceptible al código de script, su prefijo some/local/path/ garantiza que no se pueda convertir en una URL de JS. Sin embargo, un atacante podría especificar cualquier ruta relativa a un archivo de imagen en el mismo servidor, lo que podría encontrar indeseable.

NB: se trata de construir URL javascript: maliciosas. Si desea utilizar valores controlados por el usuario como location.hash para la salida HTML o un contexto diferente, debe desinfectar la cadena correctamente.

    
respondido por el Arminius 01.06.2016 - 22:25
fuente
1

Sí, es un problema, tal vez incluso un gran problema, pero "XSS" probablemente no sea el término correcto.

¿Qué podría salir mal?

  1. ejecución remota de código usando svg, especialmente navegadores antiguos
  2. las imágenes fuera del sitio pierden la dirección IP de su usuario (también conocida como lat / lon), UserAgent y rendimiento de red
  3. las imágenes maliciosas en sí mismas han sido vectores, muchos días antes
  4. Un GIF especial o simplemente grande y horrible puede llevar a la página / CPU a moler
  5. las imágenes grandes se pueden usar para inyectar muchos datos conocidos para ayudar a romper el cifrado
  6. su sitio podría "anunciar" algo con lo que no quiere estar asociado
  7. una imagen externa puede confirmar que un usuario específico obtuvo un enlace específico y lo visitó

Si bien ninguno de estos son XSS tradicionales, son bummers.

Recomendaría algún tipo de opción de una lista blanca de imágenes en el sitio si desea capacidades de personalización.

    
respondido por el dandavis 02.06.2016 - 03:53
fuente

Lea otras preguntas en las etiquetas

¿Por qué es más seguro el token de acceso personal github 2FA que la frase de contraseña? Fortalecimiento de Javascript con respecto a Javascript Malware / Ransomeware como Ransome32