Inicio / Blog / Seguridad en OAuth 2.0

Seguridad en OAuth 2.0

Publicado el 20/05/2014, por David Cantón (INCIBE)
Covert Redirect Vulnerability

Tras la publicación de vulnerabilidades tan graves como HeartBleed, la publicación de fallos de seguridad como la Covert Redirect Vulnerability están teniendo una gran repercusión mediática, sobre todo cuando en la noticia aparecen gigantes de Internet como Microsoft, Facebook o Google. Sin lugar a dudas Cover Redirect es un fallo de seguridad, pero no es una vulnerabilidad de la especificación del protocolo de OAuth 2.0, aunque si se ve claramente afectado por la implementación que hacen del mismo.

Básicamente, Cover Redirect Vulnerability es una redirección no validada. Esta vulnerabilidad consiste en que ciertos sitios web, que implementan OAuth 2.0 como mecanismo de autenticación, aceptan parámetros dentro de la URL que provocan una redirección de los usuarios a otros sitios web sin la correcta validación de los mismos, incluso a dominios diferentes. El problema está en que en esta redirección se incluye datos tan sensibles como el token o código de acceso que utiliza OAuth 2.0 para acceder a la información de los usuarios.

Para ver más claramente qué es, cómo funciona y cómo afecta esta vulnerabilidad, a continuación veremos brevemente qué es OAuth 2.0, qué recomendaciones tiene la especificación para proteger los token o códigos de acceso y cómo afecta esta vulnerabilidad a OAuth 2.0 y a la seguridad de los usuarios.

OAuth 2.0 Logo

Ilustración 1 Logotipo de OAuth

QUÉ ES Y CÓMO FUNCIONA OAUTH 2.0

OAuth 2 es un protocolo abierto de autorización, desarrollado por el IETF OAuth WG, que posibilita a aplicaciones de terceros solicitar acceso limitado a los recursos de un servicio HTTP sin tener que compartir las contraseñas. En otras palabras, OAuth 2 define como un usuario puede compartir información de un sistema A (proveedor de servicio) con un sistema B (consumidor) sin que el sistema B tenga que tener acceso a la identidad o la contraseña del usuario en el sistema A. El diagrama de funcionamiento es el siguiente:

Secuencia de básica de uso de OAuth 2.0

Ilustración 2 Secuencia de básica de uso de OAuth 2.0 (developerforce)

Para ofrecer estas funcionalidades, OAuth 2.0 se basa en la generación de códigos de acceso temporales: código de acceso (Access Token), código de autorización (Authorization Token) y código de refresco (Refresh token). Estos códigos permiten a las aplicaciones de terceros acceder a la información de un usuario de forma y tiempo limitado simplemente incluyendo código en la petición. La duda que puede surgir al ver esta forma de funcionamiento es qué ocurre si alguien intercepta o captura el token de acceso, ¿podría alguien usarlo para solicitar información del usuario? La respuesta es simple SÍ. Sin embargo, como veremos, si se aplican correctamente las consideraciones de seguridad de la especificación, este mecanismo de autorización ofrece una funcionalidad y una seguridad que hace que empresas tan importantes como Google, Facebook, Microsoft o Twitter confíen en su seguridad.

CONSIDERACIONES DE SEGURIDAD DE LOS TOKENS

Para poder asegurar que este protocolo de autorización es seguro, la especificación define una serie de medidas y recomendaciones que deben cumplir todos aquellos que quieran utilizarlo. Algunas de las principales de medidas de seguridad son:

  • Todo el intercambio de token con el servidor de autorización debe hacerse bajo el protocolo de comunicaciones TLS, el cual garantiza la integridad y confidencialidad de la comunicación. De esta forma evitamos que un atacante externo pueda capturar nuestros tokens de acceso, refresco o autorización, que podrían ser usados contra los servidores de autenticación o de recursos para obtener acceso a información reservada. El ámbito o acceso del token de acceso debe ser lo más limitado posible, limitando la información a la que se puede tener acceso.
  • El servidor de autorización es el encargado de autenticar al usuario de forma segura. El servidor debe garantizar que la contraseña (o el sistema de autenticación utilizado) sea lo suficientemente robusto para autenticar a los usuarios. En aquellos casos en los que no se pueda autenticar al cliente, el servidor debe utilizar otros métodos para la validación, como por ejemplo que sea necesario configurar la dirección URI de redireccionamiento que se utiliza.
  • La generación de los tokens por parte del servidor de autorización debe garantizar que no puedan ser generados, modificados o adivinados por terceras partes. La probabilidad de que un atacante genere un token debe ser inferior a 2-128 y recomendablemente inferior o igual a 2-160.
  • El tiempo de validez de los tokens o códigos de acceso debe ser de corto y de un solo uso. Además, si el servidor de autorización detecta múltiples intentos de obtención de un token de acceso con un mismo código de autorización, el servidor debe revocar el acceso de todos los códigos de acceso concedidos en base a este token de autorización ya que este token está comprometido.
  • Los clientes que se autentiquen con el servidor de autorización deben validar el certificado TLS del servidor, comprobando así la identidad del mismo y evitando posibles ataques man-in-the-middle que pueda sufrir el protocolo o posibles ataques de Phishing que intenten suplantar la identidad del centro de autorización para obtener las credenciales del usuario.
  • Los clientes no deben almacenar los token en sitios vulnerables o accesibles, como por ejemplo serían las cookies.
  • El servidor de autorización debe comprobar que las URIs de redireccionamiento usadas tanto al conseguir el código de autorización como de acceso deben coincidir, evitando así que un atacante modifique la misma y obtenga acceso a la cuenta de un usuario.

COVER REDIRECT VULNERABILITY vs OAUTH 2.0

Como se ha visto en la sección anterior, la especificación de OAuth 2.0 hace claramente hincapié en que la transmisión de los tokens o códigos de acceso debe hacerse mediante canales seguros y que es responsabilidad del cliente que se almacene y trate de forma segura los tokens. Por estos motivos está claro que el fallo de seguridad que ha revelado Covert Redirect Vulnerability cae en la parte del cliente al no respetar la especificación, al no almacenar los token de forma segura e inaccesible para terceros.

Aun considerando que para explotar esta vulnerabilidad hay que comprometer la aplicación cliente o "convencer" al usuario de realizar alguna acción, se debe considerar que la vulnerabilidad de redirección no validada es una vulnerabilidad ampliamente extendida, estando presente en el Top 10 de OWASP (Open Web Application Security Project),que es una fundación sin ánimo de lucro que tiene como objetivo determinar y combatir las causas que hacen que el software sea inseguro.

Debido a esta razón, tanto los proveedores de los servicios de autorización OAuth 2.0 como incluso la propia especificación deberán implementar mecanismos que impidan un uso indiscriminado y sin limitación. Algunas de estas posibles medidas podría ser la implementación de listas blancas que propuso el descubridor de esta vulnerabilidad, Wang Jing , como implementa LinkedIn, o que el token este asociado al dominio desde el que se creó y que no pueda ser usado por terceros.

Dado que implementar una solución que evite esta debilidad por parte de los centros de autorización no es fácil, deberán ser en primer lugar las aplicaciones y webs que utilizan el protocolo las que revisen su implementación del protocolo y garanticen un almacenamiento seguro de los tokens para evitar la propagación de los mismos en posibles redirecciones fuera de su dominio.

CONCLUSIÓN

OAuth 2.0 es una especificación un protocolo abierto de autorización que aporta una gran funcionalidad facilitando tanto a usuarios como a los responsables de servicios web la autenticación de los mismos utilizando las credenciales de servicios tan ampliamente difundidos como Google, Facebook o Twitter. La especificación, de octubre del 2012, tiene muy presente en su descripción todas las medidas de seguridad que deben de implementar los proveedores de este servicio para que su uso sea lo más seguro posible. Sin embargo deja en manos de las aplicaciones de terceros, que usan OAuth, toda la responsabilidad del control y almacenamiento seguro de los tokens o códigos de acceso.

En conclusión, estamos ante una vulnerabilidad de difícil explotación y de complicada solución rápida, pero que no afecta sensiblemente a la funcionalidad para la que está diseñada. Una vez conocida la vulnerabilidad las aplicaciones web que usan este servicio es responsabilidad de las mismas tomar las medidas para corregir esta vulnerabilidad de redireccionamiento no validado.