Cross Site Request Falsificación (CSRF) se suele evitar con uno de los métodos siguientes:¿Cómo prevenir CSRF en una aplicación RESTful?
- Comprobar árbitro - símbolo
- inserción REST pero poco fiable en la forma y almacenar el token en la sesión del servidor - no es realmente REST
- URIs un tiempo crípticos - REST no por la misma razón como tokens
- enviar la contraseña manualmente para esta solicitud (no la contraseña almacenada en caché se utiliza con autenticación HTTP) - REST pero no es conveniente
Mi idea es utilizar un secreto de usuario, un identificador críptico pero estático y JavaScript para generar tokens.
<form method="POST" action="/someresource" id="7099879082361234103">
<input type="hidden" name="token" value="generateToken(...)">
...
</form>
GET /usersecret/john_doe
obtenidos por el JavaScript del usuario autenticado.- Respuesta:
OK 89070135420357234586534346
Este secreto es conceptualmente estático, pero se puede cambiar cada día/hora ... para mejorar la seguridad. Esta es la única cosa confidencial. - Leer la forma críptica (pero estática para todos los usuarios!) Id con JavaScript, procesarla junto con el secreto de usuario:
generateToken(7099879082361234103, 89070135420357234586534346)
- enviar el formulario junto con el token generado en el servidor.
- Dado que el servidor conoce el secreto de usuario y el id. De formulario, es posible ejecutar la misma función generateToken que el cliente antes de enviar y comparar ambos resultados. Solo cuando ambos valores sean iguales, la acción será autorizada.
¿Hay algún problema con este enfoque, a pesar de que no funciona sin JavaScript?
Adición:
Su usersecret no es exclusivo del usuario, un atacante simplemente necesita obtener ese número y ajustar sus scripts para usar el nuevo cálculo. ¿Cómo está autenticando usuarios si no tiene ningún estado? – Mike
El secreto de usuario es único por usuario y solo se puede recuperar después de la autenticación (HTTP básico o autenticación resumida o autenticación de certificado) – deamon