¿Un CSRF no autenticado sigue siendo un CSRF?

4

OWASP define falsificación de solicitudes entre sitios (CSRF) como

  

un ataque que obliga a un usuario final a ejecutar acciones no deseadas en una web   aplicación en la que se autentican actualmente .

(énfasis mío)

Un ejemplo de ataque es el enlace http://example.com/logout enviado a un usuario autenticado que, al hacer clic en él, se desconecta. Conseguimos cambiar el estado del sistema (en ese caso, el inicio de sesión del usuario) haciendo que el usuario haga clic en el enlace que le proporcionamos.

Ahora imagine un sistema de votación donde todos puedan votar, sin importar si están autenticados o no. El sistema no realiza un seguimiento de quién votó (lo que obviamente es un problema).

Puedo reproducir sin limitaciones las llamadas HTTP que aumentarán el contador de votación. ¿Enviar ese enlace de reproducción a otra persona que (sin haber iniciado sesión) haga clic en él y aumente el contador de votos se considerará una vulnerabilidad CSRF?

Mi opinión es que esto no es un CSRF porque:

  • nos falta la parte "autenticada" de la definición (que sería para la semántica)
  • Creo que la intención de esta clasificación era resaltar que un atacante puede hacer que ejecutes comandos que de otro modo no podría hacer (porque necesitas autenticarse). El caso del voto no autenticado arriba es IMO mejor descrito por A4 (Control de acceso roto)
pregunta WoJ 22.04.2017 - 13:01
fuente

1 respuesta

1
  

¿Enviar el enlace de reproducción a otra persona que (sin haber iniciado sesión) haga clic en él y aumente el contador de votos se considerará una vulnerabilidad CSRF?

Verificando la entrada OWASP 2013 en CSRF , su escenario de ataque ( en mi opinión) parece describir algo similar a su ejemplo:

  

La aplicación le permite a un usuario enviar una solicitud de cambio de estado que no incluye nada secreto.   Por lo tanto, el atacante construye una solicitud que transferirá dinero de la cuenta de la víctima a la cuenta del atacante y luego incrusta este ataque en una solicitud de imagen o iframe almacenado en varios sitios bajo el control del atacante.

En el caso de su ejemplo, debido a que no se requiere autenticación, ese escenario es válido en todos los casos: un atacante puede hacer que un usuario emita una solicitud contra su sitio, lo que provocará un cambio de estado.

Creo que la mención de OWASP de la sesión que se autentica refleja una suposición de su parte sobre lo que se requeriría para efectuar cambios de estado en un sitio. No creo que la autenticación sea de hecho parte de la definición de CSRF - la entrada de wikipedia en CSRF menciona:

  

CSRF comúnmente tiene las siguientes características:

     
  • Se trata de sitios que dependen de la identidad de un usuario.
  •   
  • Explota la confianza del sitio en esa identidad.
  •   
  • Engaña al navegador del usuario para que envíe solicitudes HTTP a un sitio de destino.
  •   
  • Se trata de solicitudes HTTP que tienen efectos secundarios.
  •   

Así que creo que, de hecho, podría considerar que su aplicación es vulnerable a CSRF: un usuario puede ser obligado a emitir una solicitud con efectos secundarios, y esa solicitud siempre tendrá éxito (y, al menos en teoría, podría estar vinculada a la IP del usuario, por ejemplo).

No estoy seguro de que CSRF esté puramente en permitir que un atacante "haga algo que no podría hacer de otra manera". Creo que se podría argumentar que se trata de hacer que un usuario haga algo que no podría haber hecho de otra manera .

    
respondido por el iwaseatenbyagrue 22.04.2017 - 13:50
fuente

Lea otras preguntas en las etiquetas