<summary><strong>Aprende hacking en AWS desde cero hasta experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén [**merchandising oficial de PEASS & HackTricks**](https://peass.creator-spring.com)
* Descubre [**La Familia PEASS**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
OAuth ofrece varias versiones, con información fundamental accesible en la [documentación de OAuth 2.0](https://oauth.net/2/). Esta discusión se centra principalmente en el ampliamente utilizado [tipo de concesión de código de autorización OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), proporcionando un **marco de autorización que permite que una aplicación acceda o realice acciones en la cuenta de un usuario en otra aplicación** (el servidor de autorización).
Considera un sitio web hipotético _**https://ejemplo.com**_, diseñado para **mostrar todas tus publicaciones en redes sociales**, incluidas las privadas. Para lograr esto, se emplea OAuth 2.0. _https://ejemplo.com_ solicitará tu permiso para **acceder a tus publicaciones en redes sociales**. En consecuencia, aparecerá una pantalla de consentimiento en _https://redessociales.com_, describiendo los **permisos solicitados y el desarrollador que realiza la solicitud**. Tras tu autorización, _https://ejemplo.com_ obtiene la capacidad de **acceder a tus publicaciones en tu nombre**.
- **propietario de recursos**: Tú, como **usuario/entidad**, autorizas el acceso a tu recurso, como tus publicaciones en redes sociales.
- **servidor de recursos**: El **servidor que gestiona las solicitudes autenticadas** después de que la aplicación ha asegurado un `token de acceso` en nombre del `propietario de recursos`, por ejemplo, **https://redessociales.com**.
- **aplicación cliente**: La **aplicación que busca autorización** del `propietario de recursos`, como **https://ejemplo.com**.
- **servidor de autorización**: El **servidor que emite `tokens de acceso`** a la `aplicación cliente` tras la autenticación exitosa del `propietario de recursos` y la obtención de autorización, por ejemplo, **https://redessociales.com**.
- **client\_id**: Un identificador público y único para la aplicación.
- **client\_secret:** Una clave confidencial, conocida únicamente por la aplicación y el servidor de autorización, utilizada para generar `tokens de acceso`.
- **response\_type**: Un valor que especifica **el tipo de token solicitado**, como `código`.
- **scope**: El **nivel de acceso** que la `aplicación cliente` está solicitando al `propietario de recursos`.
- **redirect\_uri**: La **URL a la que se redirige al usuario después de la autorización**. Normalmente debe coincidir con la URL de redirección preregistrada.
- **state**: Un parámetro para **mantener datos a través de la redirección del usuario hacia y desde el servidor de autorización**. Su singularidad es fundamental para servir como un **mecanismo de protección CSRF**.
- **grant\_type**: Un parámetro que indica **el tipo de concesión y el tipo de token que se devolverá**.
- **code**: El código de autorización del `servidor de autorización`, utilizado junto con `client_id` y `client_secret` por la aplicación cliente para adquirir un `token de acceso`.
- **access\_token**: El **token que la aplicación cliente utiliza para las solicitudes de API** en nombre del `propietario de recursos`.
- **refresh\_token**: Permite a la aplicación **obtener un nuevo `token de acceso` sin volver a solicitar al usuario**.
1. Accedes a [https://ejemplo.com](https://ejemplo.com) y seleccionas el botón "Integrar con Redes Sociales".
2. El sitio luego envía una solicitud a [https://redessociales.com](https://redessociales.com) solicitando tu autorización para permitir que la aplicación de https://ejemplo.com acceda a tus publicaciones. La solicitud está estructurada de la siguiente manera:
5. https://example.com utiliza este `código`, junto con su `client_id` y `client_secret`, para realizar una solicitud del lado del servidor y obtener un `access_token` en tu nombre, lo que permite acceder a los permisos a los que has dado consentimiento:
El `redirect_uri` es crucial para la seguridad en las implementaciones de OAuth y OpenID, ya que dirige hacia dónde se envían los datos sensibles, como códigos de autorización, después de la autorización. Si está mal configurado, podría permitir a los atacantes redirigir estas solicitudes a servidores maliciosos, lo que habilitaría el secuestro de cuentas.
Las técnicas de explotación varían según la lógica de validación del servidor de autorización. Pueden ir desde la coincidencia estricta de rutas hasta la aceptación de cualquier URL dentro del dominio o subdirectorio especificado. Los métodos comunes de explotación incluyen redirecciones abiertas, traversal de rutas, explotación de regex débiles e inyección de HTML para robo de tokens.
Además del `redirect_uri`, otros parámetros de OAuth y OpenID como `client_uri`, `policy_uri`, `tos_uri` y `initiate_login_uri` también son susceptibles a ataques de redirección. Estos parámetros son opcionales y su soporte varía entre servidores.
Para aquellos que apuntan a un servidor OpenID, el punto de descubrimiento (`**.well-known/openid-configuration**`) a menudo lista detalles de configuración valiosos como `registration_endpoint`, `request_uri_parameter_supported` y "`require_request_uri_registration`. Estos detalles pueden ayudar a identificar el punto de registro y otros detalles de configuración del servidor.
Como se menciona en este informe de recompensa por errores [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html) podría ser posible que la **URL de redirección se refleje en la respuesta** del servidor después de que el usuario se autentique, siendo **vulnerable a XSS**. Carga útil posible para probar:
En las implementaciones de OAuth, el mal uso u omisión del **parámetro `state`** puede aumentar significativamente el riesgo de ataques de **falsificación de solicitudes entre sitios (CSRF)**. Esta vulnerabilidad surge cuando el parámetro `state` no se utiliza, se utiliza como un valor estático o no se valida correctamente, lo que permite a los atacantes eludir las protecciones CSRF.
Los atacantes pueden explotar esto interceptando el proceso de autorización para vincular su cuenta con la cuenta de una víctima, lo que puede llevar a posibles **tomas de control de cuentas**. Esto es especialmente crítico en aplicaciones donde se utiliza OAuth con fines de **autenticación**.
Se han documentado ejemplos del mundo real de esta vulnerabilidad en varios desafíos de **CTF** y **plataformas de hacking**, destacando sus implicaciones prácticas. El problema también se extiende a integraciones con servicios de terceros como **Slack**, **Stripe** y **PayPal**, donde los atacantes pueden redirigir notificaciones o pagos a sus cuentas.
1.**Sin verificación de correo electrónico en la creación de la cuenta**: Los atacantes pueden crear anticipadamente una cuenta utilizando el correo electrónico de la víctima. Si la víctima luego utiliza un servicio de terceros para iniciar sesión, la aplicación podría vincular inadvertidamente esta cuenta de terceros a la cuenta precreada del atacante, lo que lleva a un acceso no autorizado.
2.**Explotando la laxa verificación de correo electrónico de OAuth**: Los atacantes pueden explotar servicios de OAuth que no verifican correos electrónicos registrándose con su servicio y luego cambiando el correo electrónico de la cuenta al de la víctima. Este método también conlleva riesgos de acceso no autorizado a la cuenta, similar al primer escenario pero a través de un vector de ataque diferente.
Identificar y proteger los parámetros secretos de OAuth es crucial. Mientras que el **`client_id`** se puede divulgar de forma segura, revelar el **`client_secret`** plantea riesgos significativos. Si el `client_secret` se ve comprometido, los atacantes pueden explotar la identidad y confianza de la aplicación para **robar `access_tokens`** e información privada.
Una vulnerabilidad común surge cuando las aplicaciones manejan erróneamente el intercambio del `code` de autorización por un `access_token` en el lado del cliente en lugar del lado del servidor. Este error conduce a la exposición del `client_secret`, lo que permite a los atacantes generar `access_tokens` bajo la apariencia de la aplicación. Además, a través de la ingeniería social, los atacantes podrían aumentar privilegios agregando alcances adicionales a la autorización de OAuth, explotando aún más el estado de confianza de la aplicación.
Una vez que el cliente tenga el **código y el estado**, si se **refleja dentro del encabezado Referer** cuando navega a una página diferente, entonces es vulnerable.
El **código de autorización debería existir solo por un tiempo limitado para reducir la ventana de tiempo en la que un atacante puede robarlo y usarlo**.
**[Revisa este post](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)**
En este informe de recompensa por errores: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/) puedes ver que el **token** que **AWS Cognito** devuelve al usuario podría tener **suficientes permisos para sobrescribir los datos del usuario**. Por lo tanto, si puedes **cambiar el correo electrónico del usuario por un correo electrónico de otro usuario**, podrías **tomar el control** de otras cuentas.
Como se [**mencionó en este artículo**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), los flujos de OAuth que esperan recibir el **token** (y no un código) podrían ser vulnerables si no verifican que el token pertenezca a la aplicación.
Esto se debe a que un **atacante** podría crear una **aplicación compatible con OAuth e iniciar sesión con Facebook** (por ejemplo) en su propia aplicación. Luego, una vez que una víctima inicie sesión con Facebook en la **aplicación del atacante**, el atacante podría obtener el **token de OAuth del usuario otorgado a su aplicación y usarlo para iniciar sesión en la aplicación de OAuth de la víctima utilizando el token de usuario de la víctima**.
Por lo tanto, si el atacante logra que el usuario acceda a su propia aplicación de OAuth, podrá tomar el control de la cuenta de la víctima en aplicaciones que esperan un token y no verifican si el token fue otorgado a su ID de aplicación.
Según [**este artículo**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), era posible hacer que una víctima abriera una página con un **returnUrl** que apuntara al host del atacante. Esta información se **almacenaría en una cookie (RU)** y en un **paso posterior**, el **prompt** le **preguntará** al **usuario** si desea dar acceso a ese host del atacante.
Para evitar este prompt, era posible abrir una pestaña para iniciar el **flujo de OAuth** que establecería esta cookie RU utilizando el **returnUrl**, cerrar la pestaña antes de que se muestre el prompt y abrir una nueva pestaña sin ese valor. Entonces, el **prompt no informará sobre el host del atacante**, pero la cookie se establecerá en él, por lo que el **token se enviará al host del atacante** en la redirección.
El Registro Dinámico de Clientes en OAuth sirve como un vector menos obvio pero crítico para vulnerabilidades de seguridad, específicamente para ataques de **Falsificación de Solicitudes del Lado del Servidor (SSRF)**. Este punto final permite a los servidores de OAuth recibir detalles sobre las aplicaciones cliente, incluidas URL sensibles que podrían ser explotadas.
- El **Registro Dinámico de Clientes** a menudo se mapea a `/register` y acepta detalles como `client_name`, `client_secret`, `redirect_uris` y URLs para logotipos o Conjuntos de Claves Web JSON (JWKs) a través de solicitudes POST.
- Esta característica se adhiere a las especificaciones establecidas en **RFC7591** y **OpenID Connect Registration 1.0**, que incluyen parámetros potencialmente vulnerables a SSRF.
- El proceso de registro puede exponer inadvertidamente a los servidores a SSRF de varias maneras:
- **`logo_uri`**: Una URL para el logotipo de la aplicación cliente que podría ser recuperado por el servidor, desencadenando SSRF o llevando a XSS si la URL se maneja incorrectamente.
- **`jwks_uri`**: Una URL al documento JWK del cliente, que si se crea maliciosamente, puede hacer que el servidor realice solicitudes salientes a un servidor controlado por el atacante.
- **`sector_identifier_uri`**: Hace referencia a una matriz JSON de `redirect_uris`, que el servidor podría recuperar, creando una oportunidad de SSRF.
- **`request_uris`**: Enumera los URIs de solicitud permitidos para el cliente, que pueden ser explotados si el servidor recupera estos URIs al inicio del proceso de autorización.
- Se puede desencadenar SSRF registrando un nuevo cliente con URLs maliciosas en parámetros como `logo_uri`, `jwks_uri` o `sector_identifier_uri`.
- Mientras que la explotación directa a través de `request_uris` puede ser mitigada por controles de lista blanca, suministrar un `request_uri` preregistrado y controlado por el atacante puede facilitar SSRF durante la fase de autorización.
<summary><strong>Aprende hacking en AWS desde cero hasta experto con</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Si deseas ver tu **empresa anunciada en HackTricks** o **descargar HackTricks en PDF** ¡Consulta los [**PLANES DE SUSCRIPCIÓN**](https://github.com/sponsors/carlospolop)!
* Obtén el [**oficial PEASS & HackTricks swag**](https://peass.creator-spring.com)
* Descubre [**The PEASS Family**](https://opensea.io/collection/the-peass-family), nuestra colección exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family)
* **Únete al** 💬 [**grupo de Discord**](https://discord.gg/hRep4RUj7f) o al [**grupo de telegram**](https://t.me/peass) o **síguenos** en **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Comparte tus trucos de hacking enviando PRs a los repositorios de** [**HackTricks**](https://github.com/carlospolop/hacktricks) y [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud).
