Creo que estás mezclando algunas amenazas y vectores de ataque diferentes aquí.
Amenaza: MITM olfateando o configurando tokens
Ubicación: wifi público
Cómo mitigar: Use HTTPS para que la conexión esté protegida a través de TLS / SSL. También se recomienda el indicador de seguridad de la cookie, y una política de HSTS con precarga.
Amenaza: XSS
Ubicación: a través de internet
Qué es: un atacante que inyecta código JavaScript en la página, ya sea incitando a su víctima a visitar una URL para un ataque "XSS reflejado", o almacenando un script en la base de datos del sistema que no está codificado correctamente en la salida para un Ataque "almacenado XSS". Cuando se ejecuta la carga útil de ataque, proviene del navegador y la IP de la víctima.
Cómo mitigar: codifique correctamente los valores de salida, implemente una Política de seguridad de contenido, establezca X-XSS-Protection y X-Content-Type-Options encabezados HTTP, establezca la marca HttpOnly en las cookies.
Amenaza: CSRF
Ubicación: a través de internet
Qué es: el atacante incita a su víctima a visitar el sitio del atacante o un sitio comprometido por el atacante que luego realiza una solicitud maliciosa a un buen sitio en el que la víctima también ha iniciado sesión. Cuando se ejecuta la carga útil de ataque, proviene del navegador y la IP de la víctima.
Cómo mitigar: genere un token aleatorio por sesión que se pasa fuera del mecanismo de cookies (también conocido como Synchronizer Token Pattern ).
Tus puntos
Me preguntaba qué impide a un atacante generar su propia cuenta.
token
Nada: sin embargo, si ha asociado el token con la sesión del usuario, el inicio de sesión de Bob no puede usar el token CSRF de Alice y viceversa. Por lo tanto, cualquier atacante no podrá usar su propio token en un ataque CSRF. Una buena ubicación de almacenamiento es el mecanismo de sesión del lado del servidor que proporcionan muchos marcos web.
Luego comencé a exigir que la IP de los clientes también se almacenara y verificara
durante la validación Pero esto no sería seguro si nuestro atacante y
la víctima estaba en la misma red, como un punto de acceso público a WiFi.
Un ataque CSRF proviene del navegador de la víctima. Por lo tanto, la dirección IP será la misma que el resto de la sesión de la víctima. Al volver a leer el párrafo, ahora me doy cuenta de que es posible que no haya hecho referencia a una situación de Man-In-The-Middle como describí anteriormente, sin embargo, lo he dejado para completar.
Mi intento de solución: colocar una cookie en el navegador de cada usuario
y para marcar su ficha con el valor de la cocinera para que pueda estar seguro
que no es un ataque XSS.
XSS es un tipo diferente de ataque. Si tiene una vulnerabilidad XSS, la mayoría de los mecanismos de protección CSRF son inútiles o están gravemente comprometidos.
El mecanismo que describe parece ser el Encrypted Token Pattern que sea También es una forma válida de mitigar CSRF.