CSRF Contramedidas

5

Estoy trabajando en un libro sobre seguridad de aplicaciones web y dice que una contramedida CSRF efectiva es asignar un token pseudoaleatorio temporal a acciones sensibles realizadas por usuarios autenticados, y que los tokens secretos deben durar poco tiempo. Ser impredecible para ser efectivo.

Mi pregunta es ¿cuál es el rango de seguridad si el token es el UID establecido a través de la base de datos del usuario? Presumiblemente, si he hecho mi trabajo correctamente, nadie sabrá cuál es su UID y tampoco hay forma de que se pueda encontrar.

    
pregunta Melanie Sumner Smith 07.01.2013 - 15:01
fuente

3 respuestas

4

Los tokens CSRF tienen dos partes: una parte generalmente se establece como parte de los campos de formulario ocultos, que no son tan difíciles de encontrar.

Fraseados de manera diferente, los tokens CSRF se almacenan tanto en el lado del cliente como en el lado del servidor. Cualquier cosa almacenada en el lado del cliente, debe asumir que se puede encontrar / leer / extraer. (Supongamos que se puede comprometer).

Por lo tanto, es imposible asegurarse de que nadie sepa cuál es su UID. Por eso debería cambiar con frecuencia (lo más cerca posible de "en cada solicitud").

Relacionados: enlace

Buen recurso: enlace

No mencionaste tu plataforma. (.NET, Java, PHP, etc). Muchas plataformas tienen bibliotecas bien definidas para tratar esto. Recomiendo usar uno de esos si es posible.

    
respondido por el David Stratton 07.01.2013 - 15:42
fuente
4

Indescriptible los UID son difíciles ... Recuerde que el atacante a menudo puede permitirse ser paciente, por lo que puede hacer muchos intentos con varios valores de UID potenciales. Para que el atacante realmente no pueda adivinar el UID, tendría que generarlos al azar en un espacio suficientemente grande: esto significa usar un cryptographically fuerte PRNG (su servidor ya tiene uno, llamado /dev/urandom en sistemas similares a Unix, o CryptGenRandom() en Windows) y haciendo que el UID sea lo suficientemente grande para que el atacante no golpee uno "por casualidad" (por lo que debería ser, como mínimo , de 12 bytes, preferiblemente más).

A menos que uses un UID grande y aleatorio, no puedes confiar en que el atacante desconoce el UID.

Otro punto, que otros han señalado, es que el token CSRF es, por naturaleza, un dato que el cliente envía junto con su solicitud (la petición será aceptada en virtud de venir con ese token). Por lo tanto, si el UID es el token CSRF, entonces ha pasado por el cliente ... en ese momento, solo podemos asumir que el atacante obtuvo una copia del mismo. Esta es toda la idea detrás del concepto de "las fichas secretas deberían durar poco tiempo": para hacer la vida más difícil para el atacante, acortando la ventana de tiempo durante la cual se puede usar una ficha secreta agarrada. El UID es de larga duración, por lo que no es apropiado para ese rol.

    
respondido por el Thomas Pornin 07.01.2013 - 17:31
fuente
2

Como ya se mencionó, el UID se enviará como parte de la solicitud HTTP. Esto se puede ver fácilmente mirando el tráfico HTTP sin procesar utilizando un rastreador de red como wireshark o usando un proxy HTTP (burp).

Si un usuario descubre el UID, es posible derivar el UID para otros usuarios y subvertir la protección CSRF.

Use un UID aleatorio (no UID estático) en cada solicitud y verifíquelo en el componente del lado del servidor (controlador y lo mismo).

    
respondido por el fixulate 07.01.2013 - 17:06
fuente

Lea otras preguntas en las etiquetas