Qué usar como 'estado' en el flujo de trabajo OAuth2 Authorization Code Grant

6

Estoy usando la protección csrf en mi aplicación web.

Ahora estoy planeando desencadenar un flujo de trabajo de concesión de código de autorización OAuth2, comenzando con una plantilla estática abierta en una nueva ventana del navegador usando window.open(myOAuth2StartEndpoint?oauthstuff&state=mystate) .

Pero como en este caso, la variable mystate está expuesta dentro de una etiqueta estática href al iniciar el flujo de trabajo, me pregunto si es peligroso exponer mi token de csrf predeterminado como mystate . Puedo hacer un chequeo csrf dentro de myOAuth2StartEndpoint , por lo que el token no está expuesto de forma gratuita, pero ¿es suficiente?

Si no, ¿hay recomendaciones sobre cómo manejar este caso?

    
pregunta bebbi 30.10.2015 - 16:40
fuente

2 respuestas

2

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.

  1. El usuario hace clic en un enlace en el sitio web del cliente y es redirigido al formulario de autenticación del proveedor
  2. 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:

  1. 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

  2. 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.

  3. 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.

    
respondido por el Gudradain 02.11.2015 - 16:33
fuente
0

state es información que pasa el RP (proveedor de recursos) a la IP (proveedor de identidad) y se espera que la IP envíe la misma información de vuelta.

En mi caso, utilicé state en mi implementación de JavaEE OpenID Connect como la URL de la aplicación correspondiente a la URL que se solicitó originalmente en el RP antes de que se muestre la pantalla de inicio de sesión del OP.

Lo protegí utilizando un cifrado simétrico y luego lo codificó en base 64url. Junto con la validación de que es una URL válida y es relativa a la raíz de la aplicación cuando se resuelve contra la raíz de la aplicación. La clave simétrica es aleatoria y no se pasa fuera del RP.

Si quisiera una implementación más segura (pero se restringiría a las IP que admiten nonce) codificaría la URL de origen y un nonce juntos y me aseguraría de que se extraiga el valor de nonce decodificado. El nonce puede actuar como una sal.

Nota adicional

Otras direcciones IP pueden enviar un valor state diferente al RP. Aunque eso generalmente implica que hay datos no estándar que el RP pasa a la IP y se entienden entre ellos. Por ejemplo, se puede pasar un state secundario y, dependiendo del procesamiento de IP, puede enviar el otro estado si es necesario.

    
respondido por el Archimedes Trajano 02.11.2015 - 17:22
fuente

Lea otras preguntas en las etiquetas