¿Qué es, OAuth?

Por /

¿Qué es OAuth?

OAuth es un marco de autorización de uso común que permite que los sitios web y las aplicaciones web soliciten acceso limitado a la cuenta de un usuario en otra aplicación. Fundamentalmente, OAuth permite al usuario otorgar este acceso sin exponer sus credenciales de inicio de sesión a la aplicación solicitante. Esto significa que los usuarios pueden ajustar qué datos quieren compartir en lugar de tener que ceder el control total de su cuenta a un tercero.

El proceso básico de OAuth se usa ampliamente para integrar funciones de terceros que requieren acceso a ciertos datos de la cuenta de un usuario. Por ejemplo, una aplicación puede usar OAuth para solicitar acceso a su lista de contactos de correo electrónico para que pueda sugerir personas con las que conectarse. Sin embargo, el mismo mecanismo también se utiliza para proporcionar servicios de autenticación de terceros, lo que permite a los usuarios iniciar sesión con una cuenta que tienen en un sitio web diferente.

Vulnerabilidades de autenticación OAuth 2.0

Mientras navega por la web, es casi seguro que se ha topado con sitios que le permiten iniciar sesión con su cuenta de redes sociales. Lo más probable es que esta función se cree utilizando el popular marco OAuth 2.0. OAuth 2.0 es muy interesante para los atacantes porque es extremadamente común e inherentemente propenso a errores de implementación. Esto puede dar lugar a una serie de vulnerabilidades, lo que permite a los atacantes obtener datos confidenciales del usuario y, potencialmente, eludir la autenticación por completo.

En esta sección, le enseñaremos cómo identificar y explotar algunas de las vulnerabilidades clave encontradas en los mecanismos de autenticación de OAuth 2.0 . No se preocupe si no está muy familiarizado con la autenticación OAuth: proporcionamos mucha información básica para ayudarlo a comprender los conceptos clave que necesitará. También exploraremos algunas vulnerabilidades en la extensión OpenID Connect de OAuth . Finalmente, hemos incluido una guía sobre cómo proteger sus propias aplicaciones contra este tipo de ataques.

Aunque OAuth 2.0 es el estándar actual, algunos sitios web aún usan la versión heredada 1a. OAuth 2.0 se escribió desde cero en lugar de desarrollarse directamente a partir de OAuth 1.0. Como resultado, los dos son muy diferentes. Tenga en cuenta que el término "OAuth" se refiere exclusivamente a OAuth 2.0 en estos materiales.

Solicita una cotización del mejor escaner de vulnerabilidades de sitios web y aplicativos expuestos, con precios por anualidad e intercambio de targets, BURP SUITE ENTERPRISE es el único que lo ofrece, cambia YA!

Cotizar..

¿Cómo funciona OAuth 2.0?

OAuth 2.0 se desarrolló originalmente como una forma de compartir el acceso a datos específicos entre aplicaciones. Funciona definiendo una serie de interacciones entre tres partes distintas, a saber, una aplicación cliente, un propietario de recursos y el proveedor de servicios OAuth.

  • Aplicación cliente – El sitio web o aplicación web que quiere acceder a los datos del usuario.
  • Propietario del recurso : el usuario a cuyos datos desea acceder la aplicación cliente.
  • Proveedor de servicios OAuth – El sitio web o aplicación que controla los datos del usuario y el acceso a los mismos. Admiten OAuth al proporcionar una API para interactuar tanto con un servidor de autorización como con un servidor de recursos.

Existen numerosas formas diferentes de implementar el proceso OAuth real. Estos se conocen como «flujos» de OAuth o «tipos de concesión». En este tema, nos centraremos en los tipos de concesión «código de autorización» e «implícita», ya que estos son, con mucho, los más comunes. En términos generales, ambos tipos de subvenciones implican las siguientes etapas:

  1. La aplicación cliente solicita acceso a un subconjunto de los datos del usuario, especificando qué tipo de concesión quieren usar y qué tipo de acceso quieren.
  2. Se solicita al usuario que inicie sesión en el servicio OAuth y dé explícitamente su consentimiento para el acceso solicitado.
  3. La aplicación cliente recibe un token de acceso único que prueba que tiene permiso del usuario para acceder a los datos solicitados. Exactamente cómo sucede esto varía significativamente según el tipo de subvención.
  4. La aplicación cliente utiliza este token de acceso para realizar llamadas a la API y obtener los datos relevantes del servidor de recursos.

Antes de aprender cómo se usa OAuth para la autenticación, es importante comprender los fundamentos de este proceso básico de OAuth. Si es completamente nuevo en OAuth, le recomendamos que se familiarice con los detalles de los dos tipos de concesión que vamos a cubrir antes de seguir leyendo.

Autenticación OAuth

Aunque originalmente no estaba diseñado para este propósito, OAuth también se ha convertido en un medio para autenticar a los usuarios. Por ejemplo, probablemente esté familiarizado con la opción que ofrecen muchos sitios web para iniciar sesión con su cuenta de redes sociales existente en lugar de tener que registrarse en el sitio web en cuestión. Siempre que vea esta opción, es muy probable que esté basada en OAuth 2.0.

Para los mecanismos de autenticación de OAuth, los flujos básicos de OAuth siguen siendo prácticamente los mismos; la principal diferencia es cómo la aplicación cliente utiliza los datos que recibe. Desde la perspectiva del usuario final, el resultado de la autenticación OAuth es algo que se parece en gran medida al inicio de sesión único (SSO) basado en SAML. En estos materiales, nos centraremos exclusivamente en las vulnerabilidades en este caso de uso similar al SSO.

La autenticación OAuth generalmente se implementa de la siguiente manera:

  1. El usuario elige la opción de iniciar sesión con su cuenta de redes sociales. Luego, la aplicación cliente usa el servicio OAuth del sitio de redes sociales para solicitar acceso a algunos datos que puede usar para identificar al usuario. Esta podría ser la dirección de correo electrónico que está registrada con su cuenta, por ejemplo.
  2. Después de recibir un token de acceso, la aplicación cliente solicita estos datos al servidor de recursos, generalmente desde un /userinfopunto final dedicado.
  3. Una vez que ha recibido los datos, la aplicación cliente los usa en lugar de un nombre de usuario para iniciar sesión. El token de acceso que recibió del servidor de autorización se usa a menudo en lugar de una contraseña tradicional.

Puede ver un ejemplo simple de cómo se ve esto en el siguiente laboratorio. Simplemente complete la opción «Iniciar sesión con las redes sociales» mientras envía el tráfico a través de Burp, luego estudie la serie de interacciones de OAuth en el historial del proxy. Puede iniciar sesión con las credenciales wiener:peter. Tenga en cuenta que esta implementación es deliberadamente vulnerable; le enseñaremos cómo explotar esto más adelante.

¿Cómo surgen las vulnerabilidades de autenticación OAuth?

Las vulnerabilidades de autenticación de OAuth surgen en parte porque la especificación de OAuth es relativamente vaga y flexible por diseño. Aunque hay un puñado de componentes obligatorios necesarios para la funcionalidad básica de cada tipo de subvención, la gran mayoría de la implementación es completamente opcional. Esto incluye muchos ajustes de configuración que son necesarios para mantener seguros los datos de los usuarios. En resumen, hay muchas oportunidades para que se introduzcan malas prácticas.

Uno de los otros problemas clave con OAuth es la falta general de funciones de seguridad integradas. La seguridad depende casi por completo de que los desarrolladores usen la combinación correcta de opciones de configuración e implementen sus propias medidas de seguridad adicionales, como una validación de entrada sólida. Como probablemente se haya dado cuenta, hay mucho que asimilar y es bastante fácil equivocarse si no tiene experiencia con OAuth.

Dependiendo del tipo de concesión, los datos altamente confidenciales también se envían a través del navegador, lo que presenta varias oportunidades para que un atacante los intercepte.

Identificación de la autenticación OAuth

Reconocer cuándo una aplicación utiliza la autenticación OAuth es relativamente sencillo. Si ve una opción para iniciar sesión con su cuenta desde un sitio web diferente, esta es una fuerte indicación de que se está utilizando OAuth.

La forma más confiable de identificar la autenticación OAuth es hacer un proxy de su tráfico a través de Burp y verificar los mensajes HTTP correspondientes cuando usa esta opción de inicio de sesión. Independientemente del tipo de concesión de OAuth que se utilice, la primera solicitud del flujo siempre será una solicitud al /authorizationextremo que contiene una serie de parámetros de consulta que se utilizan específicamente para OAuth. En particular, preste atención a los parámetros client_id, redirect_uriy . response_typePor ejemplo, una solicitud de autorización generalmente se verá así:

GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1 Host: oauth-authorization-server.com

Reconocimiento

Hacer un reconocimiento básico del servicio OAuth que se utiliza puede orientarlo en la dirección correcta cuando se trata de identificar vulnerabilidades.

No hace falta decir que debe estudiar las diversas interacciones HTTP que componen el flujo de OAuth; repasaremos algunas cosas específicas a tener en cuenta más adelante. Si se utiliza un servicio OAuth externo, debería poder identificar el proveedor específico a partir del nombre de host al que se envía la solicitud de autorización. Como estos servicios proporcionan una API pública, a menudo hay documentación detallada disponible que debería brindarle todo tipo de información útil, como los nombres exactos de los puntos finales y qué opciones de configuración se están utilizando.

Una vez que conozca el nombre de host del servidor de autorización, siempre debe intentar enviar una GETsolicitud a los siguientes puntos finales estándar:

  • /.well-known/oauth-authorization-server
  • /.well-known/openid-configuration

Estos a menudo devolverán un archivo de configuración JSON que contiene información clave, como detalles de funciones adicionales que pueden ser compatibles. Esto a veces le informará sobre una superficie de ataque más amplia y funciones compatibles que pueden no mencionarse en la documentación.

Solicita una cotización del mejor escaner de vulnerabilidades de sitios web y aplicativos expuestos, con precios por anualidad e intercambio de targets, BURP SUITE ENTERPRISE es el único que lo ofrece, cambia YA!

Cotizar..

Explotación de vulnerabilidades de autenticación OAuth

Pueden surgir vulnerabilidades en la implementación de OAuth de la aplicación cliente, así como en la configuración del propio servicio OAuth. En esta sección, le mostraremos cómo explotar algunas de las vulnerabilidades más comunes en ambos contextos.

  • Vulnerabilidades en la aplicación cliente
    • Implementación incorrecta del tipo de concesión implícita.
    • LABORATORIOS de protección CSRF defectuosa.
  • Vulnerabilidades en el servicio OAuth
    • Fuga de códigos de autorización y tokens de acceso 
    • Validación de alcance defectuosa
    • Registro de usuario no verificado

Vulnerabilidades en la aplicación cliente de OAuth

Las aplicaciones de los clientes suelen utilizar un servicio OAuth acreditado y reforzado que está bien protegido contra exploits ampliamente conocidos. Sin embargo, su propio lado de la implementación puede ser menos seguro.

Como ya mencionamos, la especificación de OAuth está relativamente vagamente definida. Esto es especialmente cierto con respecto a la implementación por parte de la aplicación cliente. Hay muchas partes móviles en un flujo de OAuth, con muchos parámetros opcionales y ajustes de configuración en cada tipo de concesión, lo que significa que hay muchas posibilidades de errores de configuración.

Implementación incorrecta del tipo de concesión implícita

Debido a los peligros que presenta el envío de tokens de acceso a través del navegador, el tipo de concesión implícita se recomienda principalmente para aplicaciones de una sola página. Sin embargo, también se usa a menudo en aplicaciones web clásicas de cliente-servidor debido a su relativa simplicidad.

En este flujo, el token de acceso se envía desde el servicio OAuth a la aplicación cliente a través del navegador del usuario como un fragmento de URL. Luego, la aplicación cliente accede al token mediante JavaScript. El problema es que si la aplicación quiere mantener la sesión después de que el usuario cierre la página, necesita almacenar los datos del usuario actual (normalmente una ID de usuario y el token de acceso) en algún lugar.

Para resolver este problema, la aplicación del cliente a menudo enviará estos datos al servidor en una POSTsolicitud y luego asignará al usuario una cookie de sesión, lo que hará que inicie sesión de manera efectiva. Esta solicitud es aproximadamente equivalente a la solicitud de envío de formulario que podría enviarse como parte de un inicio de sesión clásico basado en contraseña. Sin embargo, en este escenario, el servidor no tiene secretos ni contraseñas para comparar con los datos enviados, lo que significa que es de confianza implícita.

En el flujo implícito, esta POSTsolicitud se expone a los atacantes a través de su navegador. Como resultado, este comportamiento puede generar una vulnerabilidad grave si la aplicación cliente no verifica correctamente que el token de acceso coincida con los demás datos de la solicitud. En este caso, un atacante puede simplemente cambiar los parámetros enviados al servidor para hacerse pasar por cualquier usuario.

Protección CSRF defectuosa

Aunque muchos componentes de los flujos de OAuth son opcionales, algunos de ellos son muy recomendables a menos que haya una razón importante para no usarlos. Un ejemplo de ello es el state parámetro.

Idealmente, el state parámetro debería contener un valor indescifrable, como el hash de algo vinculado a la sesión del usuario cuando inicia por primera vez el flujo de OAuth. Luego, este valor se pasa de un lado a otro entre la aplicación cliente y el servicio OAuth como una forma de token CSRF para la aplicación cliente. Por lo tanto, si observa que la solicitud de autorización no envía un stateparámetro, esto es extremadamente interesante desde la perspectiva de un atacante. Potencialmente significa que ellos mismos pueden iniciar un flujo de OAuth antes de engañar al navegador de un usuario para que lo complete, de forma similar a un ataque CSRF tradicional . Esto puede tener graves consecuencias dependiendo de cómo la aplicación cliente utilice OAuth.

Considere un sitio web que permita a los usuarios iniciar sesión utilizando un mecanismo clásico basado en contraseña o vinculando su cuenta a un perfil de redes sociales mediante OAuth. En este caso, si la aplicación no usa el stateparámetro, un atacante podría potencialmente secuestrar la cuenta de un usuario víctima en la aplicación cliente vinculándola a su propia cuenta de redes sociales.

Tenga en cuenta que si el sitio permite a los usuarios iniciar sesión exclusivamente a través de OAuth, state se podría decir que el parámetro es menos crítico. Sin embargo, no usar un state parámetro aún puede permitir que los atacantes construyan ataques CSRF de inicio de sesión, mediante los cuales se engaña al usuario para que inicie sesión en la cuenta del atacante.

Cotizar Burp Suite

Fuga de códigos de autorización y tokens de acceso

Quizás la vulnerabilidad basada en OAuth más infame es cuando la configuración del propio servicio OAuth permite a los atacantes robar códigos de autorización o tokens de acceso asociados con las cuentas de otros usuarios. Al robar un código o token válido, el atacante puede acceder a los datos de la víctima. En última instancia, esto puede comprometer completamente su cuenta: el atacante podría iniciar sesión como el usuario víctima en cualquier aplicación cliente que esté registrada con este servicio OAuth.

Según el tipo de concesión, se envía un código o token a través del navegador de la víctima al /callback punto final especificado en el redirect_uri parámetro de la solicitud de autorización. Si el servicio OAuth no valida este URI correctamente, un atacante puede construir un ataque similar a CSRF, engañando al navegador de la víctima para que inicie un flujo OAuth que enviará el código o el token a un correo electrónico controlado por el atacante redirect_uri.

En el caso del flujo de código de autorización, un atacante puede potencialmente robar el código de la víctima antes de que se use. Luego pueden enviar este código al /callback extremo legítimo de la aplicación del cliente (el original redirect_uri) para obtener acceso a la cuenta del usuario. En este escenario, un atacante ni siquiera necesita conocer el secreto del cliente o el token de acceso resultante. Siempre que la víctima tenga una sesión válida con el servicio OAuth, la aplicación del cliente simplemente completará el intercambio de código/token en nombre del atacante antes de iniciar sesión en la cuenta de la víctima.

Tenga en cuenta que el uso state o nonce la protección no impiden necesariamente estos ataques porque un atacante puede generar nuevos valores desde su propio navegador.

Los servidores de autorización más seguros requerirán redirect_uri que se envíe un parámetro al intercambiar el código también. Luego, el servidor puede verificar si esto coincide con el que recibió en la solicitud de autorización inicial y rechazar el intercambio si no es así. Como esto sucede en las solicitudes de servidor a servidor a través de un canal trasero seguro, el atacante no puede controlar este segundo redirect_uri parámetro.

Validación de redirect_uri defectuosa

Debido a los tipos de ataques vistos en el laboratorio anterior, se recomienda que las aplicaciones cliente proporcionen una lista blanca de sus URI de devolución de llamada genuinas al registrarse con el servicio OAuth. De esta forma, cuando el servicio OAuth recibe una nueva solicitud, puede validar el redirect_uri parámetro contra esta lista blanca. En este caso, proporcionar un URI externo probablemente generará un error. Sin embargo, aún puede haber formas de omitir esta validación.

Al auditar un flujo de OAuth, debe intentar experimentar con el redirect_uri parámetro para comprender cómo se valida. Por ejemplo:

  • Algunas implementaciones permiten una variedad de subdirectorios al verificar solo que la cadena comience con la secuencia correcta de caracteres, es decir, un dominio aprobado. Debe intentar eliminar o agregar rutas arbitrarias, parámetros de consulta y fragmentos para ver qué puede cambiar sin desencadenar un error.

  • Si puede agregar valores adicionales al redirect_uri parámetro predeterminado, es posible que pueda aprovechar las discrepancias entre el análisis del URI por parte de los diferentes componentes del servicio OAuth. Por ejemplo, puedes probar técnicas como:

    https://default-host.com &@foo.evil-user.net#@bar.evil-user.net/

    Si no está familiarizado con estas técnicas, le recomendamos que lea nuestro contenido sobre cómo eludir las defensas comunes de SSRF y CORS .

  • Ocasionalmente puede encontrarse con vulnerabilidades de contaminación de parámetros del lado del servidor. Por si acaso, debería intentar enviar redirect_uri parámetros duplicados de la siguiente manera:

    https://oauth-authorization-server.com/?client_id=123&redirect_uri=client-app.com/callback&redirect_uri=evil-user.net
  • Algunos servidores también dan un tratamiento especial a los localhost URI, ya que a menudo se usan durante el desarrollo. En algunos casos, cualquier URI de redirección que comience con localhost puede permitirse accidentalmente en el entorno de producción. Esto podría permitirle eludir la validación registrando un nombre de dominio como localhost.evil-user.net.

Es importante tener en cuenta que no debe limitar sus pruebas a solo probar el redirect_uri parámetro de forma aislada. En la naturaleza, a menudo necesitará experimentar con diferentes combinaciones de cambios en varios parámetros. A veces, cambiar un parámetro puede afectar la validación de otros. Por ejemplo, cambiar el response_mode de query a a fragment veces puede alterar por completo el análisis del redirect_uri, lo que le permite enviar URI que, de lo contrario, estarían bloqueados. Del mismo modo, si nota que web_message se admite el modo de respuesta, esto a menudo permite una gama más amplia de subdominios en el archivo redirect_uri.

Robo de códigos y tokens de acceso a través de una página proxy

Contra objetivos más robustos, es posible que, independientemente de lo que intente, no pueda enviar correctamente un dominio externo como redirect_uri. Sin embargo, eso no significa que sea hora de rendirse.

En esta etapa, debe tener una comprensión relativamente buena de qué partes del URI puede manipular. La clave ahora es utilizar este conocimiento para intentar acceder a una superficie de ataque más amplia dentro de la propia aplicación cliente. En otras palabras, intente averiguar si puede cambiar el redirect_uri parámetro para que apunte a otras páginas en un dominio incluido en la lista blanca.

Intente encontrar formas en las que pueda acceder con éxito a diferentes subdominios o rutas. Por ejemplo, el URI predeterminado a menudo estará en una ruta específica de OAuth, como /oauth/callback, que es poco probable que tenga subdirectorios interesantes. Sin embargo, es posible que pueda usar trucos de recorrido de directorios para proporcionar cualquier ruta arbitraria en el dominio. Algo como esto:

https://client-app.com/oauth/callback/../../example/path

Puede interpretarse en el back-end como:

https://client-app.com/example/path

Una vez que identifique qué otras páginas puede establecer como el URI de redirección, debe auditarlas en busca de vulnerabilidades adicionales que pueda usar para filtrar el código o el token. Para el flujo de código de autorización , debe encontrar una vulnerabilidad que le dé acceso a los parámetros de consulta, mientras que para el tipo de concesión implícita, debe extraer el fragmento de URL.

Una de las vulnerabilidades más útiles para este propósito es una redirección abierta. Puede usar esto como un proxy para reenviar a las víctimas, junto con su código o token, a un dominio controlado por el atacante donde puede alojar cualquier script malicioso que desee.

Tenga en cuenta que para el tipo de concesión implícita, robar un token de acceso no solo le permite iniciar sesión en la cuenta de la víctima en la aplicación cliente. Como todo el flujo implícito se realiza a través del navegador, también puede usar el token para realizar sus propias llamadas API al servidor de recursos del servicio OAuth. Esto puede permitirle obtener datos de usuario confidenciales a los que normalmente no puede acceder desde la interfaz de usuario web de la aplicación cliente.

Además de los redireccionamientos abiertos, debe buscar cualquier otra vulnerabilidad que le permita extraer el código o el token y enviarlo a un dominio externo. Algunos buenos ejemplos incluyen:

  • JavaScript peligroso que maneja parámetros de consulta y fragmentos de URL
    Por ejemplo, los scripts de mensajería web inseguros pueden ser excelentes para esto. En algunos escenarios, es posible que deba identificar una cadena de dispositivos más larga que le permita pasar el token a través de una serie de secuencias de comandos antes de filtrarlo finalmente a su dominio externo.
  • Vulnerabilidades XSS
    Aunque los ataques XSS pueden tener un gran impacto por sí solos, normalmente hay un pequeño período de tiempo en el que el atacante tiene acceso a la sesión del usuario antes de que cierre la pestaña o navegue. Como elHTTPOnly atributo se usa comúnmente para las cookies de sesión, un atacante a menudo tampoco podrá acceder a ellas directamente usando XSS. Sin embargo, al robar un código o token OAuth, el atacante puede obtener acceso a la cuenta del usuario en su propio navegador. Esto les da mucho más tiempo para explorar los datos del usuario y realizar acciones dañinas, lo que aumenta significativamente la gravedad de la vulnerabilidad XSS.
  • Vulnerabilidades de inyección de HTML
    En los casos en los que no pueda inyectar JavaScript (por ejemplo, debido a restricciones de CSP o filtrado estricto), aún puede usar una inyección de HTML simple para robar códigos de autorización. Si puede apuntar el redirect_uri parámetro a una página en la que puede inyectar su propio contenido HTML, es posible que pueda filtrar el código a través del Referer encabezado. Por ejemplo, considere el siguiente img elemento: <img src="evil-user.net">. Al intentar obtener esta imagen, algunos navegadores (como Firefox) enviarán la URL completa en el Referer encabezado de la solicitud, incluida la cadena de consulta.

Validación de alcance defectuosa

En cualquier flujo de OAuth, el usuario debe aprobar el acceso solicitado según el alcance definido en la solicitud de autorización. El token resultante permite que la aplicación cliente acceda solo al ámbito aprobado por el usuario. Pero en algunos casos, es posible que un atacante «actualice» un token de acceso (ya sea robado u obtenido mediante una aplicación cliente malintencionada) con permisos adicionales debido a una validación defectuosa por parte del servicio OAuth. El proceso para hacer esto depende del tipo de subvención.

Actualización de alcance: flujo de código de autorización

Con el tipo de concesión de código de autorización , los datos del usuario se solicitan y envían a través de una comunicación segura de servidor a servidor, que un atacante externo normalmente no puede manipular directamente. Sin embargo, todavía es posible lograr el mismo resultado registrando su propia aplicación cliente con el servicio OAuth.

Por ejemplo, supongamos que la aplicación de cliente malicioso del atacante inicialmente solicitó acceso a la dirección de correo electrónico del usuario utilizando el openid email alcance. Una vez que el usuario aprueba esta solicitud, la aplicación de cliente malicioso recibe un código de autorización. A medida que el atacante controla su aplicación cliente, puede agregar otro scope parámetro a la solicitud de intercambio de código/token que contiene el profile alcance adicional:

POST /token Host: oauth-authorization-server.com … client_id=12345&client_secret=SECRET&redirect_uri=https://client-app.com/callback&grant_type=authorization_code&code=a1b2c3d4e5f6g7h8&scope=openid%20 email%20profile

Si el servidor no valida esto contra el alcance de la solicitud de autorización inicial, a veces generará un token de acceso utilizando el nuevo alcance y lo enviará a la aplicación cliente del atacante:

{ "access_token": "z0y9x8w7v6u5", "token_type": "Bearer", "expires_in": 3600, "scope": "openid email profile", … }

Luego, el atacante puede usar su aplicación para realizar las llamadas API necesarias para acceder a los datos del perfil del usuario.

Actualización de alcance: flujo implícito

Para el tipo de concesión implícita, el token de acceso se envía a través del navegador, lo que significa que un atacante puede robar tokens asociados con aplicaciones cliente inocentes y usarlos directamente. Una vez que han robado un token de acceso, pueden enviar una solicitud normal basada en el navegador al punto final del servicio OAuth /userinfo, agregando manualmente un nuevo scope parámetro en el proceso.

Idealmente, el servicio OAuth debería validar este scope valor con el que se usó al generar el token, pero no siempre es así. Siempre que los permisos ajustados no excedan el nivel de acceso previamente otorgado a esta aplicación cliente, el atacante puede potencialmente acceder a datos adicionales sin requerir aprobación adicional del usuario.

Registro de usuario no verificado

Al autenticar a los usuarios a través de OAuth, la aplicación cliente asume implícitamente que la información almacenada por el proveedor de OAuth es correcta. Esta puede ser una suposición peligrosa de hacer.

Algunos sitios web que brindan un servicio OAuth permiten a los usuarios registrar una cuenta sin verificar todos sus detalles, incluida su dirección de correo electrónico en algunos casos. Un atacante puede explotar esto registrando una cuenta con el proveedor de OAuth utilizando los mismos detalles que un usuario objetivo, como una dirección de correo electrónico conocida. Las aplicaciones cliente pueden permitir que el atacante inicie sesión como víctima a través de esta cuenta fraudulenta con el proveedor de OAuth.

Ampliación de OAuth con OpenID Connect

Cuando se usa para la autenticación, OAuth a menudo se amplía con una capa OpenID Connect, que proporciona algunas características adicionales relacionadas con la identificación y autenticación de usuarios. Para obtener una descripción detallada de estas funciones y algunos laboratorios más relacionados con las vulnerabilidades que pueden presentar, consulte nuestro tema de OpenID Connect.

Prevención de vulnerabilidades de autenticación OAuth

Para los desarrolladores, brindamos orientación sobre cómo evitar la introducción de estas vulnerabilidades en sus propios sitios web y aplicaciones.

Si te ha gustado, ¡compártelo con tus amigos!

Entradas relacionadas

Scroll al inicio

Portal de Clientes