¿El flujo de código de autorización de OAuth 2 es vulnerable al problema del agente confuso?

Question

¿El flujo de código de autorización de OAuth 2 es vulnerable al problema del agente confuso?

#1 de Chen Xie (1 votos)

1

El problema del agente confuso (también conocido como 'The Devil Wears Prada') es una vulnerabilidad de OAuth 2 que surge cuando el protocolo se usa para la autenticación. Esencialmente, un cliente malicioso obtiene un token para un usuario y lo presenta a un segundo cliente. Si el segundo cliente acepta tokens como prueba de autenticación, el cliente malintencionado puede autenticarse como el usuario ante otro cliente.

En la mayoría de las explicaciones de esta vulnerabilidad, como enlace y OAuth flujo implícito y confuso problema adjunto , es sugirió que esto solo funciona para el flujo implícito.

Sin embargo, ¿el flujo del código de autorización no tendrá el mismo problema? Parece que un cliente malintencionado puede obtener un código de autorización para un usuario y luego ofrecer ese código de autorización a un segundo cliente. El segundo cliente ahora realiza una solicitud de backchannel al servidor de autorización, y al finalizar, el segundo cliente cree que se está comunicando con el usuario en lugar de con el cliente malintencionado.

¿Este análisis es correcto?

authorization oauth2 confused-deputy

pregunta Matthijs Melissen 05.12.2017 - 17:32

fuente

1 respuesta

Lea otras preguntas en las etiquetas authorization oauth2 confused-deputy

¿Hay alguna manera de proteger el archivo apk para que no sea descompilado? ¿Cuál es el riesgo de NO usar una clave de host para SFTP usando pysftp?

score 1 · Accepted Answer

En el flujo de subvención Authentication Code , el servidor de autenticación podrá averiguar si el código de autenticación se proporcionó a un cliente diferente al del segundo cliente.

Para obtener el código de autenticación, a continuación se emitirá una solicitud de muestra del cliente malintencionado:

GET /authorize?response_type=code&client_id=<malicious client ID>&state=xyz
        &redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb HTTP/1.1
Host: server.example.com

Tenga en cuenta que el servidor de autenticación mantiene una asignación de código de autenticación e identificación del cliente como resultado de una solicitud de código de autenticación exitosa.

Ahora el cliente malintencionado entregará este código de autenticación al URI de redirección para el segundo cliente y el segundo cliente solicitará a su vez un token de autenticación. Muestra como abajo:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=SplxlOBeZQQYbYS6WxSbIA
&redirect_uri=https%3A%2F%2Fclient%2Eexample%2Ecom%2Fcb

Tenga en cuenta que el ID y el secreto del cliente están codificados en el encabezado Authorization , como resultado, cuando el servidor de autenticación procesa dicha información, es capaz de determinar si la identificación del cliente en la solicitud coincide con la identificación del cliente que el código de autenticación fue asignado inicialmente a. En este caso, no hay una coincidencia, como resultado, el servidor de autenticación no otorgará el token de acceso en respuesta a la solicitud.

En otras palabras, la verificación de la ID del cliente realizada por el servidor de autenticación en el backend garantiza que todos los tokens devueltos a cambio del código de autorización se emitieron para su aplicación.