Es posible algún tipo de CSRF usando la etiqueta img / script para leer información sensible

3

Supongamos que tengo una API en https://mysite/api/getSensitiveData que:

  • Utiliza GET
  • Protegido con autenticación de cookies
  • Devuelve JSON con algunos datos confidenciales

Un chico malo crea un sitio en su servidor que tiene una etiqueta de imagen:

<img src="https://mysite/api/getSensitiveData"><img>

Ahora el navegador ejecutará esta solicitud y enviará la cookie y los datos se cargarán (hasta donde sé, al menos) y, como no es una imagen, no se mostrará nada.

Pero la solicitud se ejecutó en un sitio donde un tipo malo controla javascript. ¿Hay alguna forma de que la respuesta se pueda leer desde la imagen, alguna intercepción de solicitudes o algún otro método?

P.S. Tal vez hay otras posibilidades similares, no necesariamente img tag?

    
pregunta Ilya Chernomordik 26.04.2018 - 18:55
fuente

1 respuesta

5

Con solo una etiqueta de imagen - no. Para que el atacante pueda recopilar datos del punto final de la API y devolvérsela a sí mismo, tendría que tener javascript en la página bajo su control. Con las solicitudes de javascript / ajax, el navegador seguirá transmitiendo cookies y, por lo tanto, autenticará su solicitud, lo que posiblemente le permitirá recibir una respuesta y luego enviarla a un nuevo servidor.

Sin embargo, cualquier intento de hacer esto irá en conflicto con la misma política de origen en el navegador. Esto indica que si un script solicita un documento de un sitio con un host, puerto o protocolo diferente, la respuesta será denegada desde el script a menos que el sitio de destino lo apruebe explícitamente.  La forma más común de aprobar solicitudes de dominios cruzados es a través de CORS. Como resultado, la única forma en que un atacante podría leer la respuesta de su punto final y recuperar los datos es si usted (el propietario del dominio) le ha dicho explícitamente a CORS que permita las credenciales y que también incluya en la lista blanca el nombre de dominio que el malicioso javascript se está ejecutando en.

Para sortear esa restricción, el atacante tendría que tener su propio javascript para ejecutarse en su dominio, pero en ese momento estamos hablando de un ataque XSS, y ya casi está. Hay formas de evitar que los datos regresen a un atacante, incluso en el caso de un ataque XSS exitoso usando encabezados CSP bien configurados, pero los encabezados CSP pueden ser difíciles de corregir y aún no tienen un amplio soporte de navegador (en particular IE ).

El análogo más cercano a lo que estás hablando es el secuestro XSSI / JSON. Estas son técnicas diferentes para evitar las restricciones de la misma política de origen en el navegador:

enlace

Sin embargo, las técnicas que permiten eludir estas restricciones se han aplicado en gran medida en los navegadores modernos, lo que hace que la vulnerabilidad sea mucho menos relevante:

enlace

Siempre es posible que se encuentren tales debilidades adicionales en el futuro, en cuyo caso hay algunas técnicas para protegerse contra XSSI (h / t Xavier59):

enlace

    
respondido por el Conor Mancone 26.04.2018 - 21:04
fuente

Lea otras preguntas en las etiquetas