¿Alguien ve alguna desventajas de hacer lo siguiente para evitar CSRF?

Question

Me pregunto si el siguiente método completamente Evitar CSRF, y ser compatible con todos los usuarios.

Aquí está:

En la forma basta con incluir un parámetro adicional que es: encrypted(user's userID + request time). Del lado del servidor acaba de descifrar y asegúrese de que está el ID de usuario correcto y el momento petición era razonable reciente.

Aparte de que alguien olfateando el tráfico del usuario o romper el cifrado, se esta completamente seguro? ¿Hay algunas desventajas?

Answer 1

Mientras que su método es seguro que no es estándar. La forma estándar para prevenir ataques CSRF es generar números pseudo-aleatorios que incluya en un campo oculto y también en una galleta y luego en el lado del servidor de comprobar que ambos valores coinciden. Echar un vistazo a este posterior .

Answer 2

Una desventaja importante es que su página se 'tiempo de espera' si el usuario deja su navegador abierto más largo que el período de tiempo a decidir es razonable antes de publicar el formulario. Yo prefiero los sitios que no se precipiten a su usuario a cometer su acción a menos que la acción es inherentemente sensible al tiempo.

Answer 3

Está no es completamente segura, ya que puede ser posible que un sitio de atacar a adivinar el ID de usuario.
Si utiliza una clave de cifrado por sesión, es seguro. (Pero entonces todo lo que necesita hacer es enviar la clave de crudo, y que ya está seguro)

Además, recuerde sobre las zonas horarias y relojes inexactas.

Answer 4

Se debe trabajar, sí. Aunque yo sugeriría que utilice un número aleatorio para el ID de usuario al crear nuevos usuarios, en lugar de un simple incrementando el número (obviamente, asegúrese de que es única cuando se crea el usuario). De esta manera, es difícil para un atacante "conjetura".

Answer 5

Tener el ID de usuario y una DateTime es un comienzo, pero también desea un valor de número pseudo aleatorio preferentemente con alta entropía, además, en el canario token. Básicamente, es necesario reducir la previsibilidad de la ficha en una página en un contexto dado. Tener sólo el ID de usuario y una DateTime en teoría, podría ser posible romper después de algún tiempo, ya que no es "suficientemente aleatoria". Una vez dicho esto, los ataques CSRF son generalmente guión y no se controla directamente, por lo que dependiendo de la exposición de su aplicación, puede ser suficiente.

Además, asegúrese de usar un algoritmo de cifrado más seguro, como Rijndael / AES con una clave de bits suficientes para la seguridad de su aplicación y un vector de inicialización aleatoria de pseudo.

Answer 6

El sistema de seguridad que ha propuesto es vulnerable a los ataques.

Bloque sistemas de cifrado AES como se utilizan comúnmente como generadores de números aleatorios muy seguras. Se les llama CSPRNGs . Sin embargo, como cualquier generador de números aleatorios que tiene que preocuparse acerca de lo que se siembra con el algoritmo. En este caso se utiliza user's userID + request time ambos de los cuales el atacante puede saber, su aplicación no tiene una clave o IV así que supongo que son NULL. El atacante está construyendo el pedido, por lo que siempre sabrá la request time. El userId es probable que una clave principal, si tiene 100 usuarios entonces el atacante podría forjar 100 solicitudes y uno de ellos va a funcionar. Sin embargo, el atacante podría simplemente quiere forzar al administrador para cambiar su contraseña, el administrador de contenidos por lo general tiene una clave primaria de 1.

No reinventar la roncha , muy buenos generadores de números aleatorios ya se han construido y también hay bibliotecas anti-CSRF.