¿Cómo prevenir mejor los ataques CSRF en una aplicación GAE?

Question

Entonces, ¿cuál es la mejor manera de prevenir un ataque XSRF para una aplicación GAE? Imagine lo siguiente:

1. Cualquiera puede ver el objeto público de un usuario, y la identificación db.Model se usa en la solicitud para averiguar qué objeto mostrar. El usuario malicioso ahora tiene la identificación.
2. El usuario malintencionado crea su propio objeto y extrae el formulario de eliminación. Ahora saben cómo eliminar un objeto con una determinada identificación.
3. El usuario malintencionado consigue que un usuario inocente envíe una solicitud de eliminación para el objeto de ese usuario.

¿Qué pasos puedo agregar para prevenir # 3? Tenga en cuenta que cuando digo ID, estoy usando la parte de ID real de la clave. Una idea que tuve fue utilizar el valor de la clave completa en las solicitudes de eliminación, pero ¿eso evitaría que un usuario malintencionado pueda resolver esto? Hasta donde sé, la clave es una combinación del tipo de clase de modelo, la identificación de la aplicación y la identificación de la instancia del objeto, por lo que probablemente podrían derivar la clave de la identificación si quisieran.

¿Alguna otra idea? Jeff escribió una publicación sobre esto , y sugirió un par de métodos: un valor de formulario oculto eso cambiaría en cada solicitud y un valor de cookie escrito a través de js en el formulario. No quiero excluir a los usuarios que no sean javascript, por lo que la solución de cookies no es buena; para el valor de formulario oculto, tendría que escribir un almacén de datos en cada solicitud que mostrara un objeto borrable, no es una situación ideal para una escalabilidad aplicación!

¿Alguna otra idea por ahí?

Answer 1

Cuando genera la página que permite al usuario eliminar un objeto, genere un token aleatorio e inclúyalo en un campo de formulario oculto. Establezca también una cookie de solo HTTP con ese valor. Cuando reciba una solicitud de eliminación, verifique que el token aleatorio del formulario y el valor de la cookie coincidan.

Tu token aleatorio no debería ser solo un número aleatorio. Debes cifrar la combinación de un número aleatorio y la identidad del usuario, para dificultar que los atacantes falsifiquen sus propios tokens. También debe usar diferentes claves de cifrado para el valor almacenado en el formulario y el valor almacenado en la cookie, por lo que si uno de los tokens se filtra, aún es difícil para un atacante falsificar el otro token.

Este enfoque verifica que la solicitud de eliminación se origina en su formulario, por la presencia del token de seguridad en el formulario; y no requiere escribir en el almacén de datos.

Este enfoque sigue siendo vulnerable a los ataques de secuencias de comandos entre sitios, donde un atacante podría recuperar el valor oculto del formulario o enviar el formulario, por lo que pruebe a fondo su sitio para detectar vulnerabilidades de secuencias de comandos entre sitios. Este enfoque también es vulnerable a " clickjacking " ataques.

Answer 2

Simple: verifique el árbitro. Es (deliberadamente) imposible establecer esto usando Javascript, formularios HTML, etc. Si está en blanco (algunos servidores proxy y referencias de franjas de navegadores) o desde su propio sitio, o más específicamente desde la fuente esperada, permita. De lo contrario, denegarlo y registrarlo.

Editar: Jeff escribió un artículo de seguimiento con un par de formas de prevenir los ataques CSRF.

Answer 3

En la respuesta del servidor que muestra el formulario, cree un hash mágico (basado en la IP del cliente + fecha / hora + sal aleatoria, lo que sea). Póngalo en una cookie y guárdelo en algún lugar del servidor. Durante el manejo de la acción de envío, verifique el hash de la cookie contra la entrada de la base de datos.

Si no existe dicho hash o es diferente, rechace el envío.

Después de enviar con éxito, puede eliminar la entrada hash, cambiar su estado a enviado, lo que le convenga.

Ese método debería protegerlo en muchos casos, pero seguramente todavía no es 100% a prueba de balas.

Realice una búsqueda de artículos sobre CSRF, tal vez encuentre algunas buenas respuestas sobre esto Stack Overflow . ;)

No haga ninguna verificación de referencias o validaciones de IP del cliente: es demasiado propenso a errores (la información de referencia puede ser borrada por el agente del usuario, un proxy o por las preferencias del usuario) y la IP del cliente puede cambiar entre la creación y el envío del formulario - no castigue al usuario por la asignación dinámica de direcciones IP.