Aplicaciones oficiales OpenID Connect / OAuth 2.0 y "falsas"

2

Mi pregunta se refiere principalmente a OpenID Connect, pero también se puede aplicar a OAuth 2.0.

Cuando se trata de un cliente de OpenID Connect que realiza el baile de "autorización" con el proveedor de OpenID Connect, el cliente envía su ID de cliente al proveedor para indicar cuál es. Esto se usa en lugares como las pantallas de "consentimiento", que muestran de manera destacada los ámbitos que está dispuesto a permitir que el cliente utilice con la parte que confía como parte de los tokens de acceso que se emitirán. La identificación del cliente también puede estar marcada como "especial" de alguna manera, como si fuera para una "aplicación oficial" podría permitir que esta aplicación omita ciertas pantallas de consentimiento que de otro modo se mostrarían a un tercero o mostrarían señales visuales prominentes para el usuario que esta es una aplicación oficial "confiable".

Mi pregunta gira en torno a cómo evitar que dichas aplicaciones sean suplantadas. Con las aplicaciones del lado del servidor, estas están protegidas mediante el uso de un "Secreto del cliente" que no está disponible para un cliente malicioso. Con los clientes basados en el navegador (que utilizan el flujo "implícito"), la "ID del cliente" está vinculada a una redirección específica posterior a la autenticación, lo que significa que un cliente malintencionado que utiliza de manera fraudulenta la ID del cliente "oficial" del cliente nunca vería el otorgado tokens, ya que el navegador redirigiría de nuevo al lugar equivocado (o la URL de redireccionamiento se rechazaría.

¿Cómo evitan las aplicaciones nativas, como las aplicaciones iOS o Android, contra este tipo de ataque donde el ID / secreto del cliente es robado de una aplicación legítima y es utilizado por una aplicación no autorizada para personificarlo durante los flujos de autenticación de OpenID Connect? ? Por lo que veo, podría "robar" la ID del Cliente (y / o el Secreto del Cliente) incrustado en la aplicación "oficial", subir una aplicación fraudulenta a la App Store / Play Store que usa dicho ID / Secreto, y luego asegúrate de que el URI de redireccionamiento que se usa es el mismo que el de la aplicación oficial. Mi aplicación rogue luego escucharía esa URL de redireccionamiento para los tokens resultantes, y durante el baile de autorización, las pantallas que se muestran al usuario afirmarán de manera prominente que esta es una aplicación "oficial" y / o que omiten esas pantallas de consentimiento por completo, aunque esto sea así. una aplicación de terceros.

(¡Lo siento por el muro de texto que conduce a la pregunta! ¡Solo quiero asegurarme de que todas mis suposiciones sean correctas! ¡Por favor, dígame si tengo algo mal!)

    
pregunta MattCotterellNZ 07.01.2018 - 22:24
fuente

1 respuesta

1

Robar el secreto del cliente es cada vez más difícil, ya que ahora se pueden almacenar mediante API de hardware para el cifrado / almacenamiento seguro en dispositivos modernos. Las aplicaciones móviles deben usarlas en la mayor medida posible.

Hace algún tiempo, el flujo recomendado para el uso de aplicaciones móviles era el flujo implícito: ningún secreto del cliente y ninguna forma de obtener un token de actualización, lo que limita la posible ventana de ataque.

En estos días recomendaría el flujo híbrido (código id_token), que permite actualizar tokens y, por lo tanto, también requiere un secreto. Ese secreto debe almacenarse de la forma más segura posible, y además debe implementar la protección PKCE. PKCE protege contra ataques de intercepción de código, no como lo que describe: una aplicación malintencionada podría robar el código de autenticación al registrar el URI / esquema de redirección. PKCE protege contra eso al exigirle que envíe un desafío de código (generado a partir de un verificador de código de cryporandom) al enviar la solicitud de autenticación. En cada solicitud al punto extremo del token, se envía el verificador. Eso le permite al IDP comparar esto con el desafío, lo que garantiza que los tokens solo se entreguen al URI de redirección correcto.

Espero que esto ayude :)

    
respondido por el Kevin Dockx 29.01.2018 - 18:55
fuente

Lea otras preguntas en las etiquetas