¿Se considera un CSRF si requiere un identificador único que no es un token CSRF, no está vinculado a la sesión del usuario?

Question

¿Se considera un CSRF si requiere un identificador único que no es un token CSRF, no está vinculado a la sesión del usuario?

#1 de rook (2 votos)
#2 de sebastian nielsen (-1 votos)

1

Considere un punto final como el siguiente. Imaginemos que este punto final actualiza una dirección del usuario que inició sesión, cambiando el código postal. La dirección a actualizar se identifica mediante la ID de la dirección ( kUj3Nkg10 ).

enlace

Es importante destacar que el identificador es una cadena alfanumérica, no un entero incremental. Si fuera un entero incremental, entonces podría predecirse. El alfanumérico no puede ser predicho o adivinado razonablemente.

Para aclarar, en el ejemplo, la identificación de la dirección se generó aleatoriamente, pero una vez que existe, nunca cambia. La ID no se basa en ningún usuario o datos de dirección específicos.

Además, una actualización de dirección es solo un ejemplo, realmente no importa lo que realmente haga la solicitud. Podría ser actualizar un número de teléfono o eliminar una dirección de correo electrónico. La clave es que este alfanumérico se utiliza para identificar la entidad y que no hay un token CSRF.

Argumento para considerarlo un CSRF

Un token CRSF solo vive y permanece válido para la sesión actual (o posiblemente incluso más corta). La ID única en cuestión sigue siendo la misma (probablemente para siempre). Por lo tanto, se debe utilizar un token CSRF. Es posible que el identificador se pueda usar en otra parte de la aplicación y que esté disponible para que lo vea otro usuario.

Argumento para no considerarlo un CSRF

Es poco probable que el atacante obtenga la ID única. Podría estar cerca de ser tan difícil obtener un token CSRF real en sí mismo.

OWASP define un CSRF como:

Cualquier aplicación que acepte solicitudes HTTP de un usuario autenticado sin tener algún control para verificar que la solicitud HTTP sea única para la sesión del usuario.

Creo que el ejemplo anterior satisface la definición de OWASP, porque la ID de dirección no es exclusiva de la sesión del usuario.

referencia OWASP

web-application web-browser session-management csrf

pregunta ServerBloke 29.11.2014 - 16:22

fuente

2 respuestas

Lea otras preguntas en las etiquetas web-application web-browser session-management csrf

Pregunta de enrutamiento del túnel VPN Con SSL: no guardar sesiones, no se envían cookies

score 2 · Answer 1

Hay CSRF cuenta de la persona que trabaja en nuestro equipo. / a>, después de todo, hay más que una forma de pelar un gato. Al considerar un sistema de protección CSRF, busque cualquier acceso directo que no exista con el patrón de token de sincronización CSRF comúnmente usado. Hay tres preocupaciones con este sistema de protección CSRF propuesto.

Caducidad : CSRF también se denomina "sesión montada", en cierto sentido, un token CSRF es muy parecido a un identificador de sesión, lo más importante que ambos deben caducar . La preocupación es que un atacante puede adivinar el valor exacto del token CSRF durante un período de tiempo ilimitado.

Recuperación del ataque : XSS se puede usar para obtener cualquier valor en cualquier página usando un XMLHTTPRequest() , que incluye tokens CSRF. Una vez que el atacante tiene el token CSRF, se les permite viajar indefinidamente en la sesión de la víctima, porque nunca caduca.

Fuga de información del remitente : enviar el token CSRF en la URL es un comportamiento riesgoso. Si en algún punto un atacante puede controlar la etiqueta href de una etiqueta <a> o la etiqueta src de una etiqueta <img> , entonces un atacante puede forzar a los navegadores a cargar contenido desde un servidor web controlado por el atacante, lo que permite el atacante para registrar el referente HTTP, que contendrá el token CSRF de la víctima.

score -1 · Answer 2

Si la ID de la dirección podría generarse a partir de una dirección específica (por ejemplo, si la ID de la dirección es una representación binaria de lat / long de la dirección especificada que luego está codificada en Base64 y luego se convierte de un lado a otro a través de un servicio de geolocalización ), entonces tiene el mismo riesgo de CSRF que originalmente.

Pero si el ID es aleatorio, entonces estás a salvo de CSRF.

Debe codificar su aplicación web para rechazar cualquier consulta con una ID no existente, o con una ID que no pertenezca al usuario en cuestión.

No importa si encripta una ID de dirección geolocalizada, porque entonces el atacante solo obtiene la ID de la dirección anterior simplemente ingresando la dirección original de la víctima en la propia cuenta de los atacantes, y de ese modo la ID se usa para cambiar la dirección de las víctimas .

Por lo tanto, necesitas usar una ID completamente aleatoria para estar seguro.