¿Es seguro usar un token CSRF varias veces?

3

Soy nuevo en el problema CSRF y estoy estudiando cómo se implementa la protección CSRF en aplicaciones populares como Facebook, Instagram, etc. Ahora estoy estudiando cómo se usa la protección CSRF en la implementación de OAuth.

Algunos servicios (Instagram, Todoist) permiten pasar un argumento adicional cuando se solicita una URL de autorización de OAuth. Este argumento se describe en Instagram:

  

Puede proporcionar un parámetro de estado opcional para llevar a través de un estado específico del servidor. Por ejemplo, puede usar esto para protegerse contra problemas CSRF.

Cuando elaboré con un code diferente el token CSRF en forma en la página donde el usuario (dis) permite el acceso a su cuenta, es el mismo en todas las solicitudes, incluso si proporciono un valor diferente para code . ¿Esta bien?

¿Tiene una idea de cómo transforman code en el token CSRF y cómo se usa este token para la protección CSRF? Por favor, ¿podría explicar cómo funciona?

EDIT1

Encontré que un token CSRF por sesión probablemente no sea un problema y generar un token único por solicitud conduce al problema de la aplicación (botón de retroceso, etc.), fuente - enlace

Pero aún no sé cómo se usa o transforma el parámetro code mencionado anteriormente en el token CSRF.

    
pregunta Artegon 27.09.2015 - 16:05
fuente

1 respuesta

1
  

¿Tienes una idea de cómo transforman code en token CSRF y cómo es   Este token utilizado para la protección CSRF? Por favor, ¿podría explicar cómo   funciona?

Estás mezclando las cosas en tu pregunta.

De tu cita de instagram:

  

Puede proporcionar un parámetro opcional de estado para llevar a cabo una   Estado específico del servidor. Por ejemplo, puedes usar esto para proteger   contra los problemas de CSRF.

Observe que es el parámetro state que se usa para la protección CSRF, y es independiente de code y cómo se intercambia por un token.

Básicamente, cuando la aplicación envía al usuario a Instagram para realizar el procedimiento de autorización, necesita una forma de garantizar que el usuario que regresa con code sea el mismo y no un atacante. Ahí es donde encaja el parámetro state , el servidor de autorización reflejará el valor que se encuentre en el parámetro state en la aplicación de llamada, lo que le permitirá funcionar como un token CSRF.

El bit importante es que a través de la parte code del proceso, el usuario-agente actúa como intermediario entre la aplicación y el servidor de autorización. El servidor de autorización tiene un code para la aplicación, pero se entrega al usuario que luego se lo entrega a la aplicación.

El intercambio del code por un token no se maneja a través del usuario-agente , el parámetro de estado ya no es necesario una vez que la aplicación tiene el código porque se comunica directamente con el servidor de autorización (idealmente autenticado con una clave API y protegido con TLS).

El código no se intercambia por un "token CSRF", el código se intercambia por un access_token que permite a la aplicación realizar operaciones en el recurso protegido (la cuenta de Instagram) en nombre del usuario.

El token CSRF enviado en el parámetro state es el "lado del cliente" de su token CSRF habitual (el que colocó en un campo de entrada oculto en sus formularios).

Dado que el token CSRF (por diseño) se enviará en las solicitudes GET , se recomienda que sean únicos y no se reutilicen. Vea el Información sobre el token en la URL de la OWASP en su edición. / p>     

respondido por el GnP 08.09.2016 - 22:49
fuente

Lea otras preguntas en las etiquetas