Aviso legal : no se pudo encontrar ninguna referencia sobre el tema, así que usaré una herramienta cuestionable llamada "lógica". Si alguien encuentra una buena referencia, por favor agrégala.
CSRF es peligroso
No hay dudas al respecto y OAuth2 no es una excepción. De hecho, hay varias formas en que puedes explotar el ataque CSRF mientras usas OAuth2. La razón es que hay varios mensajes que se envían y podrían usarse para desencadenar un ataque CSRF. La sección OAuth2 Spec Section 10.12 ofrece una buena visión general de lo que podría hacer con CSRF
Pero, veamos qué sucede en detalles cuando un usuario desea iniciar sesión usando OAuth2. En nuestro ejemplo, tendremos los siguientes actores:
- El usuario (usted y su navegador)
- El atacante (generalmente un sitio web malicioso)
- El cliente (aplicación web que está utilizando)
- El proveedor (servidor oauth2 que autentica al usuario)
Luego, veamos qué sucede desde el punto de vista del usuario cuando intenta autenticarse con el proveedor.
- El usuario hace clic en un enlace en el sitio web del cliente y es redirigido al formulario de autenticación del proveedor
- El usuario se autentica con el proveedor y es redirigido al sitio web del cliente donde también se autentica, automáticamente
¿Dónde podemos atacar?
Desde el punto de vista del usuario, son solo 2 pasos simples pero hay varios lugares donde puedes atacarlo. Uno de los problemas principales aquí es que, con frecuencia, el proveedor de OAuth2 lo redireccionará automáticamente, si ya inició sesión. Un buen ejemplo es el flujo de pila. Ver esta respuesta para más detalles:
Falsificación de solicitud de sitios cruzados OAuth2 y parámetro de estado
Así que los diferentes ataques son:
-
Un atacante puede reemplazar el código de autorización con el suyo para hacer que inicie sesión en su cuenta en lugar de la suya. Puede parecer una idea loca, pero si decide ingresar alguna información confidencial en su cuenta, ahora tiene acceso a ella. Ej .: información bancaria
-
Un atacante puede generar un enlace de proveedor válido en su máquina y luego se lo sirve. Si el proveedor se está redirigiendo automáticamente, iniciará sesión en el servicio que el atacante desea atacar.
-
El atacante le hace generar un enlace de proveedor válido desde el sitio web del cliente (solo funciona si el enlace se genera a través de una publicación / obtener en una URL estática), luego, si el proveedor se está redireccionando automáticamente, iniciará sesión. Al servicio del atacante queremos atacar.
¿Cómo protegerse contra ellos?
Simple, solo necesita pasar su token anti-falsificación CSRF en el parámetro de estado de OAuth2 para protegerse contra # 1 y # 2. Luego, para protegerse contra el # 3, debe asegurarse de que el enlace no pueda generarse sin la interacción del usuario, lo que significa proteger ese enlace con la protección CSRF. Pero volviendo a # 1 y # 2 ...
Al incluir, un token CSRF como el estado, vencerás esos ataques, ya que será imposible para el atacante proporcionarte enlaces que no has generado. Una implementación simple de un token CSRF es un número aleatorio que se almacena en la sesión y luego se incluye en cada formulario enviado por un usuario. Si el formulario contiene el token, el cliente lo considera válido. Si no lo contiene, el cliente asume que la solicitud no es válida.
Por lo general, ese token CSRF solo es accesible para el usuario / navegador y el cliente, pero en el caso de OAuth2, más partes tienen acceso a él. Para entender qué hacer, necesitamos saber cuáles son estas partes adicionales.
La respuesta: simplemente envía el token
Por lo tanto, en ese caso, se conocerá el token
- El cliente (el que lo creó)
- El usuario
- El proveedor
Es un simple viaje de ida y vuelta a través de HTTPS. Un atacante no puede insertarse en esa conversación, por lo que no tiene que preocuparse por eso.
¿Necesita proteger el token contra el proveedor?
No. Si el proveedor OAuth2 es malicioso, ya lo ha perdido. Él no necesita su token CSRF para hacerse cargo de todas sus cuentas si así lo desea. Cuando eligió usar OAuth2, básicamente lo convirtió en el dios de todas sus cuentas de usuario.
Conclusión
No se preocupe demasiado por cómo envía el token CSRF; Sólo asegúrate de enviarlo. Además, el hecho de que se envíe como un parámetro url sería otro punto a preocuparse por una contraseña permanente, pero dado que esos tokens son temporales no debería ser un gran problema.