Header Ads Widget

Ticker

6/recent/ticker-posts

Principales vulnerabilidades del cliente OAuth


Este artículo destaca algunas vulnerabilidades comunes de OAuth encontradas en aplicaciones web y móviles en 2021, junto con algunas mitigaciones para mejorar la seguridad.

La implementación de clientes web y móviles puede ser un desafío, ya que existen muchos otros factores además del trabajo de seguridad, principalmente en torno a la experiencia del usuario y la confiabilidad:

  • Redirigir el navegador del sistema para que el usuario inicie sesión
  • Manejo de puntos finales adicionales, condiciones de error y vencimiento del token
  • Lidiar con la navegación, las recargas de páginas y la navegación de múltiples pestañas
  • Soporta múltiples opciones de autenticación

Algunas soluciones a los problemas de usabilidad pueden empeorar la seguridad, mientras que las mitigaciones de este artículo tratan bien otras áreas además de la seguridad.

Clientes Web

Los clientes web suelen ser los más difíciles de proteger perfectamente debido a que tienen que ejecutar código JavaScript en un navegador, que es un entorno limitado (y en ocasiones hostil) para ejecutar código.

1. Redirecciones inseguras

Los parámetros que envía en una redirección de autorización de OpenID Connect están directamente relacionados con la seguridad, por lo tanto, utilice las recomendaciones más recientes para evitar posibles vulnerabilidades.

Los parámetros estándar deben usar Proof Key for Code Exchange (PKCE) , como lo reconoce el code_challengecampo, y también deben incluir un parámetro de estado aleatorio inadivisible:

client_id=my_client
redirect_uri=https://www.example.com
response_type=code
scope=openid
state=dMl9MPiqtX_LHL9HddqFqxRIRS4FUnbPTzB6cVszcZ4
code_challenge=9a7TInbDR662OL0zPZ6kgNDNRFHisi0r1G6qaLczpfw
code_challenge_method=S256

Una biblioteca de sonidos proporcionará estos valores correctamente, aunque en aplicaciones de alta seguridad, es posible que le preocupe que un ataque Man in the Browser (MITB) altere estos valores.

Un estándar emergente para los clientes confidenciales es utilizar JAR / PAR / JARM para que se utilicen JWT (o referencias) verificables en las solicitudes y respuestas, como protección contra la manipulación.

2. Intercepción de respuesta

Las respuestas de OAuth se devuelven en un URI de redireccionamiento y siempre deben recibirse en una URL HTTPS que haga referencia a un nombre de dominio propio:

<https://www.example.com?code=cdjn238023r&state=h802efh02r>

Durante el desarrollo, puede ser conveniente configurar URL comodín para que varios desarrolladores puedan iniciar sesión usando el nombre de host de su computadora local:

*
https://*.mydomain.com

En su lugar, debe configurar una URL absoluta para todos los sistemas implementados y evitar los redirectores abiertos . Estos podrían permitir que un atacante reciba la respuesta y luego intercambie potencialmente el código de autorización por tokens.

3. Falsificación de solicitudes entre sitios (CSRF)

CSRF ocurre cuando un atacante engaña a un navegador para que realice una acción no deseada por parte de un usuario autenticado. Un cliente web de OpenID Connect debe asegurarse de que si un atacante puede de alguna manera obtener el código de autorización de un usuario, no puede inyectarlo en su propia sesión de esta manera:

<https://www.example.com?code=cwe89n8c20e30e8ytfr&state=h802efh02efgwerfgr>

La solución estándar es validar los parámetros de 'estado' recibidos:

  • La redirección envía un valor imposible de adivinar y la aplicación web lo almacena.
  • La respuesta debe contener el mismo valor o la aplicación web lo rechazará.
  • Para obtener más detalles, consulte los documentos de IETF sobre la falsificación de solicitudes de OAuth Cross NSite .

4. Fichas filtradas en el historial del navegador

Evite las soluciones que devuelven tokens directamente en las URL de respuesta del navegador, como el flujo implícito en desuso Estos pueden incluir tokens en el historial del navegador y tienen muchos riesgos de seguridad:

https://www.example.com#token=cdjn238023r&state=h802efh02r

5. Códigos de autorización robados

Si un atacante roba de alguna manera un código de autorización, no debe poder enviarlo al punto final del token del servidor de autorización para recibir tokens.

El uso de la clave de prueba para el intercambio de código garantiza esto, ya que el code_verifiercampo es imposible de adivinar y no puede ser proporcionado por un atacante. También debe asegurarse de que el cliente web utilice un secreto de cliente, que suele ser un valor de cadena simple, aunque también es posible Mutual TLS:

grant_type: authorization_code
client_id: my_client
client_secret: cer23u0n4iuhyte
code: cdjn238023r&state=h802efh02r
redirect_uri: com.mycompany.myapp:/callback
code_verifier: 3GI6Tlm93c8Am0TcZkb4BkZh2eCycIuG4OmoWSUl-h0

Una vez que el código se intercambia por tokens, un cliente web usará tokens de acceso en el navegador para llamar a las API o usará cookies seguras para llamar a las API. De estas opciones, la primera tiene mayores vulnerabilidades.

6. Secuencias de comandos entre sitios

Después de la autenticación del usuario, si su interfaz de usuario web tiene vulnerabilidades de Cross Site Scripting (XSS) , entonces cualquier código malicioso que pueda ejecutarse puede potencialmente llamar a sus API, independientemente de si está utilizando tokens de acceso o cookies seguras:

const options = {
method: 'POST',
credentials: 'include',
headers: {
'x-csrf': readCsrfToken()
}
}
const data = await fetch(apiUrl, options);

La mitigación es tomarse los riesgos XSS muy en serio y seguir la guía de OWASP para prevenirlos como parte de su ciclo de vida de desarrollo de seguridad.

7. Credenciales de API robadas

La llamada a las API con tokens de acceso se realiza mediante código JavaScript, lo que abre más vectores de ataque para códigos maliciosos. Por lo tanto, OAuth para aplicaciones basadas en navegador recomienda el uso de un backend para frontend (BFF) para administrar tokens:

  • El BFF puede administrar un secreto de cliente al obtener tokens.
  • Una SameSite=strictcookie / solo HTTP se utiliza como credencial de API desde el navegador.
  • La cookie segura puede contener tokens si está fuertemente cifrada.
  • Las cookies seguras son 'propias' y funcionan bien en términos de usabilidad.
  • JavaScript o el navegador no tienen forma de acceder a los tokens directamente.

BFF a menudo se malinterpreta y se puede implementar con bastante facilidad conectando una API de BFF sin estado desarrollada por expertos en seguridad. Cuando se hace bien, esto mejorará y simplificará la arquitectura web.

8. Almacenamiento de tokens inseguro

Si se implementa OAuth únicamente en el navegador, a través del código JavaScript en una aplicación de página única (SPA), es un desafío lidiar con los siguientes problemas de seguridad de manera adecuada:

  • El almacenamiento de tokens de acceso en el almacenamiento local se considera inseguro.
  • El uso de tokens de actualización en el navegador se considera inseguro.

Si usa tokens en el navegador, siga estas pautas y comprenda que no hay almacenamiento seguro disponible:

  • No devuelva los tokens de actualización al navegador.
  • Mantenga el token de acceso de corta duración, quizás con una vida útil de 15 minutos.
  • Apunta a almacenar el token solo en la memoria.

9. Divulgación de información del token

Si devuelve un token de identificación al navegador, intente mantenerlo confidencial y evite incluir información de identificación personal (PII) , como nombres de usuario y direcciones de correo electrónico.

Considere usar tokens de ID mínimos y obtener información del usuario a través de una solicitud de API, que es la opción utilizada en una solución Backend para Frontend.

10. Intercepción de credenciales

Si los tokens se almacenan en la memoria del navegador dentro de un cierre privado, el código malicioso no puede leerlos directamente. Sin embargo, todavía es posible que puedan ser interceptados, como en la siguiente técnica de 'parcheo de mono' para robar un token de acceso mientras se envía:

const original = XMLHttpRequest.prototype.setRequestHeader;
XMLHttpRequest.prototype.setRequestHeader = function(key, val) {
maliciousCode(key, val)
original.call(this, key, val);
}

Una mitigación de este problema es almacenar tokens aislados del resto de la aplicación en un Web Worker , en cuyo caso este ataque en particular no funciona. Una vez más, sin embargo, la opción preferida es utilizar un Backend para Frontend, ya que el código malicioso no puede interceptar las cookies solo HTTP.

11. Exportación de credenciales

Si se intercepta un token, potencialmente se puede enviar a un sitio malicioso para un ataque más concertado a sus API. Esto se puede mitigar mediante el uso de encabezados de seguridad recomendados , incluida una Política de seguridad de contenido que evita que el código malintencionado envíe datos a sitios web o dominios de navegador que no sean de confianza:

content-security-policy:
default-src 'none';
connect-src 'self' <https://api.example.com>;
img-src 'self';
script-src 'self';
style-src 'self';

Aunque se recomienda, es posible que el usuario o un complemento del navegador desactive el CSP. Nuevamente, se prefiere una solución Backend para Frontend, ya que no hay forma de que el código JavaScript malicioso obtenga una cookie segura para enviar fuera del navegador.

12. Secuestro de sesión

Al implementar una solución OAuth únicamente en JavaScript, las acciones como que un usuario vuelva a cargar la página o abra una nueva pestaña del navegador son difíciles de administrar.

El método tradicional de lidiar con esto en un SPA era realizar una redirección del navegador en un iframe oculto que envía la cookie SSO para obtener un nuevo token de acceso. Las restricciones recientes del navegador pueden evitar que esto funcione, ya que la cookie SSO se considera de un tercero y se elimina.

El código malicioso puede potencialmente abusar de esta técnica al ejecutar el código de un botón de inicio de sesión en un iframe oculto. Esto podría permitir que los mensajes se envíen automáticamente, como una redirección de autorización para devolver un código de autorización, o una concesión de código de autorización para intercambiar el código por tokens.

Esta es una forma de secuestro de sesión , y debe asegurarse de que no devuelva tokens a un atacante. En una solución Backend para Frontend, estas acciones solo reescribían cookies seguras y un atacante no podría aprovechar el resultado del inicio de sesión.

De forma predeterminada, su servidor de autorización debe rechazar las llamadas de iframes con un encabezado de respuesta X-Frame-Options : DENY. Es una buena práctica dejar esta configuración en su lugar a menos que haya una buena razón.

Clientes móviles

Los clientes móviles tienen sus desafíos de seguridad particulares debido al riesgo de robo de dispositivos y los vectores de ataque del sistema operativo móvil.

13. Divulgación de contraseña

Algunas aplicaciones móviles utilizan la concesión de contraseña de propietario de recurso obsoleta para autenticar usuarios y obtener tokens a través de una vista web. Esto se considera deficiente tanto en términos de seguridad como de usabilidad:

  • Puede ser peligroso para la aplicación obtener acceso a la contraseña de un usuario final, especialmente porque la misma contraseña puede otorgar acceso a otros recursos para el usuario.
  • El ID de cliente y el secreto de cliente utilizados con la concesión de la contraseña pueden modificarse mediante ingeniería inversa.
  • Se recomienda a los proveedores de OIDC que bloqueen los inicios de sesión desde las vistas web comprobando la cadena del agente de usuario.
  • Una vez que una aplicación utiliza la concesión de contraseña, se bloquea con inicios de sesión basados ​​en contraseña como la única opción, y aquellos con una mejor usabilidad, como WebAuthn , no se pueden integrar.

En su lugar, utilice una opción estándar, cuya seguridad esté diseñada explícitamente para el estuche móvil, con las mejores opciones de seguridad y extensibilidad:

14. Esquema de redireccionamiento robado

La solución AppAuth más fácil de implementar es que la aplicación registre una URL de esquema personalizado del siguiente formulario para recibir la respuesta de autorización:

com.mycompany.myapp:/callback

Los sistemas operativos móviles no evitan que una aplicación malintencionada registre el mismo esquema, lo que podría hacer que esa aplicación reciba el código de autorización y luego lo cambie por tokens. La protección estándar contra este riesgo es nuevamente usar la clave de prueba para el intercambio de código .

15. Suplantación de identidad en aplicaciones móviles

El uso de PKCE no evita que una aplicación malintencionada realice ingeniería inversa de una aplicación o sus solicitudes HTTP para encontrar el ID de cliente y el URI de redireccionamiento, y luego desencadenar su propio flujo completo:

  • Redirección de autorización, que devuelve un código de autorización
  • Concesión de código de autorización, para intercambiar el código por tokens

Por esta razón, las recomendaciones de grado financiero para aplicaciones móviles recomiendan el uso de URI de redireccionamiento HTTPS. Las funciones de seguridad del sistema operativo subyacente se pueden usar para garantizar que solo las aplicaciones genuinas 'certificadas' puedan recibir respuestas de redireccionamiento de OAuth:

  • En el momento de la instalación, la firma digital de la aplicación móvil se verifica con una clave pública en línea que solo puede publicar el propietario del dominio.
  • Si este no es el caso, el registro del esquema de la aplicación fallará, como sería el caso de una aplicación maliciosa que intenta utilizar el esquema HTTPS.

Para una aplicación de iOS, esto requiere una infraestructura adicional para admitir los enlaces universales , mientras que las aplicaciones de Android usan los enlaces de la aplicación de manera equivalente.

16. Falta de prueba del cliente

En cuanto a las aplicaciones web, las aplicaciones móviles son clientes públicos de forma predeterminada, lo que limita las opciones de seguridad y aumenta el alcance de la suplantación de identidad por parte de partes malintencionadas:

  • En el momento de la autenticación, el servidor de autorización no puede verificar la identidad del cliente.

Con AppAuth, se recomienda utilizar también el registro de cliente dinámico (DCR) cuando un usuario ejecuta la aplicación por primera vez, lo que convierte la aplicación en un cliente confidencial:

  • Cada instancia de la aplicación móvil obtiene su propia ID de cliente y su propio secreto de cliente.
  • La aplicación debe utilizar el secreto único siempre que recupere tokens.
  • Los patrones de autenticación no válidos son más fáciles de detectar en los registros de auditoría
  • También son posibles opciones de seguridad mejoradas como PAR / JAR / JARM

También es posible probar la identidad de una aplicación antes de permitirle intentar autenticar a los usuarios. Esto es posible cuando se utiliza un enfoque de API de autenticación de hipermedia .

Conclusión

La implementación de clientes web y móviles seguros implica algunos riesgos sutiles, aunque OAuth tiene muchas buenas mitigaciones que han sido pensadas por los expertos. Para obtener más recursos, consulte las mejores prácticas actuales de OAuth y las principales vulnerabilidades de la API de OAuth .


Publicar un comentario

0 Comentarios