CSRF token generation

Question

Se trata de generar tokens CSRF.

Por lo general, me gustaría generar un token con sede fuera de una pieza única de datos asociados con la sesión del usuario, y el algoritmo hash y salados con una clave secreta.

Mi pregunta es en lo que respecta a la generación de fichas cuando no hay datos de usuario únicas para usarlas. No hay sesiones disponibles, las cookies no son una opción, la dirección IP y cosas de esa naturaleza no son confiables.

¿Hay alguna razón por la que no puedo incluir la cadena hash como parte de la solicitud, así? Ejemplo pseudocódigo para generar el token y incrustarla:

var $stringToHash = random() 
var $csrfToken = hash($stringToHash + $mySecretKey) 
<a href="http://foo.com?csrfToken={$csrfToken}&key={$stringToHash}">click me</a> 

Ejemplo validación del lado del servidor de la CSRF token de

var $stringToHash = request.get('key') 
var $isValidToken = hash($stringToHash + $mySecrtKey) == request.get('csrfToken') 

la cadena que se utiliza en el hash sería diferente en cada petición. Siempre que se incluya en cada solicitud, la validación del token CSRF podría continuar. Dado que es nuevo en cada solicitud y solo está incrustado en la página, el acceso externo al token no estaría disponible. La seguridad del token cae en $ mySecretKey, que solo yo conozco.

¿Es este un enfoque ingenuo? ¿Me estoy perdiendo alguna razón por la que esto no puede funcionar?

Gracias

Answer 1

CSRF TOKEN destinadas a evitar el (involuntario) las modificaciones de datos, que se aplican por lo general con las solicitudes POST.

Por lo tanto, debe incluir CSRF token para cada solicitud que cambia los datos (GET o solicitud POST).

Mi pregunta es en lo que respecta a fichas generadoras cuando no hay datos de usuario únicas para usarlas. No hay sesiones disponibles, las cookies no son una opción , la dirección IP y las cosas de esa naturaleza no son confiables.

Luego simplemente cree una identificación de usuario única para cada visitante. Incluya esa identificación en una cookie o en las URL (si las cookies están deshabilitadas).

Editar:

Consideremos el siguiente caso:

Ha iniciado sesión en su cuenta de Facebook y luego entraron a algún sitio web arbitrario.

En ese sitio hay una forma que presente, lo que indica al navegador para enviar una petición POST a su cuenta de Facebook.

Esa solicitud POST puede cambiar su contraseña o agregar un comentario, etc., porque la aplicación de Facebook lo reconoció como un usuario registrado &. (A menos que haya otro mecanismo de bloqueo, como CAPTCHA de)

Answer 2

CSRF utiliza la sesión del usuario, por lo que, si no tiene uno, no hay CSRF.

Answer 3

¿Hay alguna razón por la cual no puedo incluir la cadena al hash como parte de la solicitud también?

Los tokens CSRF tienen dos partes. El token incrustado en el formulario y un token correspondiente en otro lugar, ya sea en una cookie, almacenado en una sesión o en otro lugar. Este uso de otra parte impide que una página sea independiente.

Si incluye la cadena al hash en la solicitud, entonces la solicitud es independiente, por lo que copiar el formulario es todo lo que un atacante debe hacer, ya que tienen ambas partes del token y, por lo tanto, no hay protección.

Ponerlo en el formulario URL significa que es autocontenido, el atacante simplemente copia el formulario y la URL de envío.

Answer 4

Simplemente necesita el mismo "token" en la URL/formulario y en la cookie. Esto significa que puede hacer que su página configure la cookie token a lo que quiera (preferiblemente algún valor aleatorio) mediante JavaScript y luego simplemente pase el mismo valor en todas las solicitudes que va a su servidor (como un param o un formulario URI). campo). No es necesario que su servidor genere la cookie.

Esto es seguro siempre que confiemos en que el navegador no permite que las páginas de un dominio editen/lean cookies para otros dominios, y se supone que es bastante seguro hoy en día.

Tener su servidor generando el token supondrá que este token se puede transmitir de forma segura a su navegador sin ser recogido por ningún intento de CSRF (¿por qué correr el riesgo?). Aunque podría poner más lógica en un token generado por el servidor, pero para evitar CSRF no es necesario.

(Si estoy equivocado aquí, por favor, hágamelo saber)

Answer 5

Creo que la mejor idea para hacer hash basado en HMAC, es decir, hacer hash cifrado por algunos contraseña de esta secuencia: nombre de usuario user_id + + marca de tiempo. Cada solicitud del hash debe ser diferente, la marca de tiempo debe ser si no desea obtener una repetición simple del hash en ataque.

Answer 6

Probar base64_encode(openssl_random_pseudo_bytes(16)). https://github.com/codeguy/php-the-right-way/issues/272#issuecomment-18688498 y lo utilizaron para mi formulario de ejemplo en https://gist.github.com/mikaelz/5668195

Answer 7

aquí es un ejemplo de wtforms pitón, que generan y validan token CSRF:

https://bitbucket.org/simplecodes/wtforms/src/1939aec691af476960dfe16b4e17ba4fc070459b/wtforms/ext/csrf/session.py?at=default

Answer 8

Quiero decir su enfoque funciona, porque CSRF ataque es el atacante que utiliza el navegador de la víctima para forjar un estado de inicio de sesión, ¿por qué pueden hacerlo? porque en la mayoría de los servidores, la verificación de la sesión se basa en un ID de sesión en la cookie, y la cookie es un dato que se adjuntará automáticamente a una solicitud HTTP enviada al servidor.

Por lo tanto, hay dos factores clave para la defensa CSRF

1. generar un token desafío, y requieren cliente para pasarlo al servidor de una manera no-galleta, O param URL o en forma de post es aceptable.
2. Mantenga el token seguro como lo que hizo con el SessionID, por ejemplo, utilizando SSL.

recomiendo la lectura CSRF Prevention Cheat Sheet