jquery - you - ¿Es necesaria la protección CSRF en un formulario de registro?
proteccion csrf php (5)
En CSRF
Primero, uno tiene que dejar claro qué es CSRF en realidad.
La falsificación de solicitudes entre sitios es un tipo de vulnerabilidad maliciosa de un sitio web mediante el cual se transmiten comandos no autorizados de un usuario en el que el sitio confía.
Considere el siguiente ejemplo: un pirata informático sabe que tiene una cuenta en www.example.com, y digamos que es un sitio web en el que ha iniciado sesión y aún tiene una sesión válida en ejecución. Ahora el pirata informático puede atraerlo a abrir otro sitio web, por ejemplo, trustme.com, en el que ha publicado una imagen con el siguiente código:
<img src="http://www.example.com/users/delete"/>
Si los programadores de www.example.com realmente permitieron eliminar su cuenta a través de esa URL con una simple solicitud GET y el hacker lo sabe, simplemente al ver y cargar esa imagen con su cookie válida se eliminará su cuenta en example.com, aunque solo estabas navegando en trustme.com y parecía que estos dos sitios no tenían nada que ver entre sí.
Para resumir este ejemplo, CSRF explota la confianza que un sitio tiene en el navegador de un usuario, en este caso la confianza que tenía www.example.com en su navegador.
Utilizar esa analogía para su caso significaría explotar la confianza de su sitio en el navegador del usuario, pero esa confianza aún no se ha establecido porque el usuario aún no ha iniciado sesión cuando ve su formulario. Sin embargo, debe asegurarse de que el usuario sea redirigido cuando ya haya iniciado sesión e intente cargar la página con ese formulario nuevamente , ya que de lo contrario se puede aprovechar la confianza establecida.
Entonces, como regla general, siempre que utilice cookies y sesiones para solicitudes de validación de un usuario, es decir, para confirmar o establecer la confianza en un usuario, use la protección CSRF. Como desea establecer confianza en su usuario cuando se registra, se aplica lo mismo.
Desafortunadamente, los ataques CSRF no se limitan solo a eso. Descubrí otras dos cosas que pueden suceder (y ciertamente no se limita a eso):
1 .: El siguiente es un ingenioso ejemplo de espionaje en su cuenta, hecho posible al omitir la protección CSRF en los formularios de inicio de sesión:
- El hacker crea una cuenta en un sitio web en el que realmente confía (youtrustthis.com)
- Forja una solicitud de inicio de sesión desde su navegador con sus propias credenciales y lo engaña para que use su cuenta.
- Si no te das cuenta de que en realidad estabas navegando por youtrustthis.com como otro usuario, el atacante más tarde verá lo que hiciste "en su nombre", lo cual es más o menos lo que te está espiando.
2 .: Sin la protección CSRF, un pirata informático puede imitar su inicio de sesión o formulario de inscripción en su propio documento html y enviarlo convenientemente una y otra vez (o simplemente usar curl desde la terminal) sin que el sitio confiable note que las solicitudes no en realidad proviene de sí mismo, es decir, el formulario de inicio de sesión real en el dominio de confianza nunca se ha mostrado en su navegador y no se ha enviado desde allí. Esto le permite realizar ataques de fuerza bruta mucho más fácil. Si el usuario malintencionado intenta averiguar las credenciales, su servidor responderá con una cookie de sesión válida y confiará en ese usuario, con lo cual robará su identidad. Si se trata de un formulario de registro, podrá registrar cantidades masivas de cuentas y, por lo tanto, enviar spam a su base de datos.
Para resumir esto: Vaya con la protección CSRF. Un usuario malintencionado puede utilizar los formularios de inicio de sesión y registro no seguros para utilizar mal su sitio y espiar a sus usuarios o robar sus identidades.
Para obtener más información, también consulte esta pregunta similar (para formularios de inicio de sesión) y este documento académico . Este último tiene un capítulo específico sobre el inicio de sesión de CSRF en la página 3. Además, consulte esta hoja de información sobre prevención de CSRF .
En posibles soluciones
Como la protección CSRF usa sesiones para comparar el token generado en el lado del servidor con el que se envió desde un formulario, no puedo pensar en una forma de hacerlo solo en el lado del cliente, es decir, sin golpear la pila de Rails. El punto es que el cliente solo recibe el token después de que se genera el lado del servidor.
Rails agrega automáticamente la protección CSRF a todos los formularios de forma predeterminada al agregar un authentication_token a todos los formularios generados por el sitio.
Realmente me gustaría que mi sitio tuviera un formulario de registro simple en la página principal del sitio, que por supuesto sería una página HTML estática. Esto idealmente evitaría golpear la pila de Rails en absoluto, permitiéndome atender muchas más solicitudes a la página principal.
La desventaja de esto es que dificulta la protección CSRF.
Pero me pregunto si realmente es necesario tener protección CSRF en un formulario de inscripción, teniendo en cuenta que los ataques de CSRF generalmente dependen de que la víctima esté conectada para que se pueda explotar la confianza. El formulario de registro registraría al usuario si se valida correctamente, pero no creo que eso sirva para un atacante.
¿Existe una opinión establecida sobre esto o una solución alternativa con Rails / jQuery?
Genéricamente hablando, es una buena idea proteger sus formularios de registro contra los ataques CSRF. Considere la Búsqueda de Google y suponga que el formulario de inicio de sesión está protegido contra CSRF, pero el formulario de registro es vulnerable. Un atacante puede forzar a una víctima a registrar una nueva cuenta con las credenciales que el atacante conoce, y desde ese momento cualquier búsqueda que la víctima haga también será visible para el atacante, ya que conoce las credenciales para iniciar sesión en la cuenta de las víctimas. Esto supone que el sitio vulnerable inicia sesión inmediatamente en el usuario después del registro.
Otro escenario, con los proveedores de correo electrónico, es crear cuentas para propósitos de spam. Un atacante puede obligar a las víctimas a crear nuevas cuentas, con un CSRF en el formulario de registro, y usar esas cuentas para enviar spam. La idea es anular los mecanismos de seguridad que aceleran la creación de cuentas según la IP o el país.
Sin embargo, en un escenario específico, puede que no sea posible explotar un formulario de registro vulnerable, pero este tipo de análisis puede ser difícil para un no experto en el tema. Es una buena idea proteger la forma, pero no hay muchos escenarios donde se pueda crear un ataque exitoso, por lo que el riesgo es normalmente bajo.
Me parece que hay pocas razones técnicas para preocuparse por csrf a partir de un formulario de registro. El atacante podría engañar a alguien para que cree una nueva cuenta en su sitio: si la víctima utilizara su sitio, el atacante podría espiar sus acciones, ya que también tendría acceso a la cuenta.
El riesgo más probable es probablemente no técnico. Cuando su sitio reciba una auditoría de seguridad, tendrá que explicar por qué la RSF no es un riesgo aquí ... y probar que lo negativo es difícil ... "Appscan lo ha calificado como un agujero de seguridad crítico, ¿por qué no lo hace? ¿Por qué no puedes tener un buen informe limpio como Charles? :)
No, para esta situación específica no. Un ataque CSRF permite a un atacante explotar los derechos que tiene una víctima, por ejemplo, bank.com/pay?ammount=1000&to=34.67.978.246
No tiene sentido atacar el formulario de inicio de sesión, ya que un atacante puede iniciar sesión solo si tiene la información necesaria para un ataque exitoso en el campo de inicio de sesión (el nombre de usuario y la contraseña).
La razón por la que Rails usa la protección CSRF en el campo de inicio de sesión es simple: es mucho más simple implementar la protección CSRF a nivel mundial que para el 95% de los campos;)
Si desea almacenar en caché la página principal pero aún tiene protección CSRF (lo cual es probablemente una buena idea, como dijo Charles), puede inyectar el token de autenticidad adecuado mediante Javascript una vez que la página se haya cargado.
Hay algo de información sobre esto en http://broadcastingadam.com/2011/05/advanced_caching_in_rails/ bajo el encabezado "CSRF and form_authenticty_token". El código relevante es:
$("meta[name=''csrf-token'']").attr(''content'', ''<% Rack::Utils.escape_html(request_forgery_protection_token) %>'');
$("meta[name=''csrf-param'']").attr(''content'', ''<% Rack::Utils.escape_html(form_authenticity_token) %>'');
Con esta técnica, puede almacenar en caché toda su página de inicio, a costa de que todos los clientes realicen una solicitud adicional (pero muy pequeña y rápida) para obtener este token de autenticación.