En esta segunda parte del artículo se detallará la solución propuesta con vistas a mitigar los vectores de ataque sobre el protocolo
OAuth2 descritos en la primera parte de este artículo. Dicha solución se divide en dos partes claramente identificadas y complementarias: autenticación basada en riesgos gracias a mecanismos de identificación de cliente, y generación de
tokens autocontenidos por el servidor de autorización.
 |
| Figura 12: Mitigación de la suplantación de identidad en OAuth 2.0 (Parte 2 de 2) |
Para la primera parte de la solución, al utilizar mecanismos de identificación de cliente para llevar a cabo la autenticación basada en riesgos, lo cual puede considerarse como una violación de la privacidad del usuario, tomaremos como base la legislación vigente de
España, más concretamente la
Ley 34/2002, de 11 de julio, de servicios de la sociedad de la información y de comercio electrónico [
ref: BOE-A-2002-13758, pp. 1-32, 2014]. Se toma como base de este estudio la legislación española ya que es una de las más restrictivas a nivel mundial y se centra en proteger la privacidad del usuario.
Para la segunda parte relacionada con la generación de
tokens autocontenidos, la solución se apoyará en la representación
JSON Web Token (JWT) - utilizados en sistemas como la
implementación OAuth2 de Office 365 -para definir un conjunto de información que dificulte la suplantación de la identidad del usuario para el que fue emitido el
token.
Además, esta definición permitirá una fácil gestión de alta disponibilidad en el servidor de autorización al viajar toda la información relevante dentro del propio
token, independientemente de si es un
token de acceso, un token de refresco o un código de autorización.
Autenticación basada en riesgos
Este trabajo define la autenticación basada en riesgos como la capacidad del servidor de
OAuth2 de identificar al cliente, además de por sus credenciales de usuario, por un segundo factor en función del riesgo que el propio servidor detecte durante el proceso de autenticación. Obviamente, para poder disponer de la información necesaria para calcular el factor de riesgo, el servidor de
OAuth2 debe ser capaz de poder identificar al cliente. Para ello, se pueden utilizar dos mecanismos de identificación:
- Identificación basada en comportamiento.
- Identificación basada en la propia identidad digital de los dispositivos del cliente.
La identificación basada en comportamiento consiste en analizar las acciones que el usuario va realizando a lo largo del tiempo para poder extraer de ellas las costumbres que identifican al usuario. Por ejemplo, si un usuario realiza siempre una consumición de más o menos la misma cuantía, sobre el mismo horario y en el mismo local, dicha transacción tendrá un nivel de riesgo menor y se podrá evitar el uso del segundo factor de autenticación, que si de repente, la cuantía de la transacción cambia considerablemente o se realiza desde otro país, en cuyo caso, el riesgo será mayor y se requerirá el segundo factor de autenticación.
Este tipo de mecanismo de identificación basado en comportamiento estaría más focalizado para entornos bancarios, ya que dichos entornos disponen de la información necesaria para implementarlos. Sin embargo, este mecanismo no sería aplicable en este caso de estudio, ya que sería muy difícil disponer de la información suficiente en base a la solicitud de acceso a los recursos protegidos para poder identificar al usuario en base a dicho comportamiento.
Por otro lado, la identificación basada en la propia identidad digital de los dispositivos del cliente permite analizar, indirectamente, las costumbres del usuario en cuanto al uso de dispositivos. Por ejemplo, si el usuario siempre se autentica desde un dispositivo móvil Android con una dirección
IP perteneciente a un rango de direcciones
IP asignadas a un
ISP en concreto, dicha autenticación tendrá un menor nivel de riesgo y podrá evitarse el uso del segundo factor de autenticación, que si de repente, el usuario se autentica desde un dispositivo
iOS o desde un rango de direcciones
IP asignadas a otro
ISP.
Este tipo de mecanismo de identificación lleva siendo utilizado para realizar el seguimiento de los usuarios por Internet sin el uso de cookies desde hace ya tiempo. Para ello, se identifica al usuario gracias al compendio de información resultante, entre otras fuentes, de la información de su resolución de pantalla y de la ventana del navegador del usuario, de su huso horario, del listado ordenado de sus fuentes (
Flash) o de su cabecera
HTTP User-Agent, la cual puede contener
información como la versión del navegador y/o la del sistema operativo. Es por esto, que se considera este método de identificación cliente el idóneo para llevar a cabo la autenticación basada en riesgos propuesta en este trabajo.
Siguiendo con el mecanismo de identificación cliente elegido, un estudio reciente de la
Universidad de Lehigh en conjunción con la
Universidad de Washington ha demostrado que gracias a las
APIs que el propio navegador ofrece vía
Javascript, se podría realizar un mejor seguimiento del usuario añadiendo a la información ya descrita en el párrafo anterior,
información de su tarjeta gráfica, de su procesador, del listado de fuentes (
Javascript) o información sobre la configuración del audio del dispositivo.
Esta nueva aproximación, permite, según los investigadores, identificar de manera satisfactoria al
99,24% de los usuarios a través de todos los navegadores que tengan en el mismo dispositivo en oposición al estado del arte del
90,84% sobre un único navegador. Este último dato proporciona a este caso de estudio una identificación de cliente más fiable para calcular mejor el riesgo asociado en el proceso de autenticación. La siguiente figura 4 muestra una visión muy a alto nivel del flujo de identificación de cliente vía
Javascript propuesto.
 |
| Figura 17: Flujo de identificación cliente vía Javascript |
Además, si tenemos en cuenta la legislación vigente en España referida al seguimiento del usuario mediante la denominada
Ley de Cookies, podemos observar que al no realizar almacenamiento y posterior recuperación de datos del dispositivo de cliente, no se está en la obligación de notificar al usuario de dicho seguimiento. Obviamente hay que puntualizar, que dicho seguimiento se lleva a cabo durante el propio proceso de autenticación del usuario y que los datos obtenidos, al estar vinculados con la propia identidad del usuario, deberían ser protegidos en su almacenamiento con el mismo nivel de seguridad que tengan los datos ya existentes del usuario como se describe en la
Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.
Por tanto, teniendo en cuenta el mecanismo de identificación de cliente elegido, la legislación vigente citada, y con vistas a mejorar la usabilidad del proceso de autenticación del usuario, la siguiente
Figura 18 describe el conjunto de reglas de ejemplo que se podrían aplicar en el proceso de autenticación basado en riesgos de un servidor de
OAuth2, donde el segundo factor de autenticación sólo será solicitado en función del riesgo detectado.
 |
| Figura 18: Tabla ejemplo de reglas para calcular el factor de riesgo |
Este proceso de autenticación basado en riesgos mitigaría la problemática descrita en la consideración de seguridad del
punto 10.2 de la RFC 6749 del protocolo OAuth2 referida a mantener en secreto los credenciales del usuario para evitar la suplantación de su identidad por un tercer usuario malicioso. Esto es así ya que si consideramos el segundo factor de autenticación con la suficiente aleatoriedad, como por ejemplo, un
OTP (One-Time Password), la desaparición o aparición de dicho segundo factor basado en el riesgo detectado en el proceso de autenticación dificultaría a un tercero, la capacidad de suplantar a un usuario aunque las credenciales de dicho usuario legítimo (primer factor de autenticación) se hayan visto comprometidas.
Si existiese un usuario atacante escuchando en la red, éste sólo podría capturar el primer factor de autenticación del usuario legítimo y al intentar autenticarse con dichas credenciales, será identificado como una autenticación de riesgo y el propio servidor de
OAuth2 solicitará el segundo factor. Nótese que como premisa de este enfoque de autenticación basada en riesgos, se entiende que el usuario atacante no dispone del control de la máquina del usuario legítimo.
Para terminar, remarcar que independientemente de si durante el proceso de autenticación se ha solicitado el segundo factor de autenticación o no, el servidor de
OAuth2 siempre debería presentar la página de solicitud explícita de consentimiento al usuario como se muestra en la
Figura 20. De esta forma, aunque los servidores de
OAuth2 no permitan al usuario controlar y filtrar que permisos de los solicitados por las aplicaciones conceden o no, se mitiga por completo el ataque de redirecciones
HTTP 307 descrito en el estudio formal sobre el protocolo
OAuth2 llevado a cabo por la
Universidad de Trier de Alemania explicado en la primera parte de este artículo, ya que de realizarse la redirección con un código
HTTP 307, el cuerpo del mensaje enviado en el
POST HTTP contendrá sólo si el usuario da su consentimiento o no, y nunca sus credenciales.
 |
| Figura 20: Página de solicitud de consentimiento al usuario |
Tokens autocontenidos
En este trabajo se considera token autocontenido a aquel que contiene toda la información necesaria para identificar unívocamente tanto al cliente para el que fue emitido el token, como a las aplicaciones que están autorizadas a utilizar dicho token en su nombre. Esta información contenida en el propio token permite que aunque se viese comprometido durante su transmisión o almacenamiento y no estuviera expirado, dicho token no fuese válido si un tercero distinto del cliente o de las aplicaciones autorizadas, quisiera ganar acceso a un recurso protegido utilizándolo. Teniendo en cuenta la consideración de que toda la información del usuario, sesión y demás está contenida en el propio
token, se permite liberar de carga a los servidores de
OAuth2 mejorando así su gestión de alta disponibilidad.
Con vistas a generar tokens capaces de incluir la información suficiente para que sean identificativos unívocamente, se propone la utilización de la notación
JSON Web Token (JWT), la cual permite una representación de datos de una manera interoperable fácilmente entendible en la comunicación entre dos partes. Este tipo de notación, al ser menos verbosa que la notación XML, permite lograr una mejor interoperabilidad y rendimiento a la hora de integrar aplicaciones de organizaciones diferentes mediante, por ejemplo, servicios web, ya sean de comercio electrónico u otra índole.
Una descripción acertada, pero incompleta bajo el punto de vista de este estudio, sobre qué debe contener un
token representado en notación
JSON Web Token para ser identificativos por sí mismos, se puede encontrar en la
RFC 7662 que define la introspección de los tokens de OAuth2. En dicha
RFC, se define la existencia de un servicio en los propios servidores de
OAuth2 que permite a los recursos protegidos consultar si un determinado
token está activo o no, y extraer metadatos a partir del
token como información del identificador de cliente, quién emitió el
token u otros.
Siguiendo una definición aproximadamente igual a la anterior
RFC citada, existe un trabajo aún en borrador que define el uso de los
JSON Web Token autocontenidos como parámetros "
state", los cuales, además de contener metadatos dentro del token, permiten a los clientes enviarlos en las peticiones a los servidores de
OAuth2 como
tokens anti-CSRF.
Este estudio considera la descripción de los
tokens autocontenidos descritos en las
RFCs anteriormente citadas, como una descripción incompleta, ya que desde el punto de vista de un recurso protegido, en base a la información que contienen los metadatos asociados al
token y la que el recurso protegido sería capaz de extraer de la identificación del cliente, no existe una coincidencia unívoca.
Esto es así, ya que en el peor de los casos, un recurso protegido tendrá a su disposición como identificación del cliente la dirección
IP de origen de la petición y la cabecera
HTTP User-Agent, y por otro lado, a partir del token podrá obtener metadatos como el identificador de cliente de la aplicación que solicitó el token, el usuario que autorizó su emisión u otras. Debido a esto, si un token se viese comprometido durante su transmisión o almacenamiento, como por ejemplo en la fuga de información a través de la
cabecera HTTP Referer descrita en la sección de vectores de ataque del presente documento, un tercer usuario malicioso podría suplantar fácilmente a la aplicación que solicitó el
token con dicho
token comprometido.
Analizando en profundidad el contenido de los campos incluidos dentro de los
JSON Web Token, se puede comprobar que dichos campos son idénticos a los propuestos en la definición del protocolo
OpenID Connect. Si se observa la
Figura 24 se puede percibir como los campos representados en los
JSON Web Token intentan simular la meta información contenida dentro de los certificados
X.509.
 |
Figura 24: Campos comunes entre el protocolo OpenID Connect y
la RFP 7662 de introspección de tokesn OAuth 2.0 |
Este intento de simulación plantea un error de identificación grave en los procesos de autenticación, ya que en un proceso de autenticación basado en
JSON Web Token, el propio
token tiene identidad por sí mismo como si fuera una cookie muy elaborada, mientras que si realizamos una autenticación basada en certificados
X.509, además de disponer de la clave pública del certificado y su meta información, se requiere de la firma de un reto aleatorio con la clave privada del certificado, causa por la cual, un certificado
X.509 público por sí mismo sin dicho reto aleatorio firmado por la clave privada no representa una identidad. Por este motivo, este estudio propone añadir a la especificación de la
RFC 7662 que define la introspección de los
tokens de
OAuth2 los campos descritos en la siguiente tabla:
 |
| Figura 25: Nuevos campos propuestos |
Los tres primeros campos permitirían al recurso protegido, a partir del
token proporcionado y la identificación del cliente más básica de la que podría disponer, ser capaz de comprobar que el
token que le han presentado proviene de quien dice ser, pudiendo rechazarlo incluso aunque no estuviese expirado. Por otro lado, el cuarto campo, permitiría tener una mejor trazabilidad del uso de los distintos recursos protegidos por parte del usuario y de las aplicaciones gracias a la gestión de un identificador de sesión único asociado a cada proceso de solicitud de
token. Esto último daría al recurso protegido la capacidad de gestionar su estado, de ser necesario, en base a dicho identificador con la certeza de que la comprobación de la integridad de dicho identificador de sesión será delegada en el propio servidor de
OAuth2.
Al incluir información que identifica unívocamente al usuario dentro del propio
token (y como
token nos referimos tanto al
token de acceso, al
token de refresco como al código de autorización), dicha información debería ir cifrada mediante la representación
JSON Web Encryption (JWE) que se describe en la
RFC 7516.
Este cifrado del contenido del
JSON Web Token permitirá a la aplicación cliente tratar dicho
token como un
token opaco o bearer cuando en realidad, su propia identidad de cliente ha permitido la generación de un
token con un funcionamiento similar al descrito para los "
token proof" en la
RFC 6819 de consideraciones de seguridad de
OAuth2. Dichos
"token proof" obligan al cliente a realizar una acción que pruebe su identidad cada vez que quiera utilizarlo, por eso, la solución propuesta en este estudio implica un menor desarrollo en las aplicaciones cliente ya que el propio cliente, al iniciar un proceso de autenticación con el servidor de
OAuth2 o durante el propio uso de los recursos protegidos, se está identificando a sí mismo con su identidad de cliente de manera transparente.
Para terminar, remarcar que el uso de esta propuesta de
tokens autocontenidos mitigaría los riesgos tanto de los vectores de ataque basados en implementación descritos en el presente documento, como los ataques de fuga de información mediante la cabecera
HTTP referer, redirecciones no controladas, gestión “
inocente” de la integridad de la sesión por parte del recurso protegido y confusión del
IdP descritos en el estudio formal sobre el protocolo
OAuth2 llevado a cabo por la
Universidad de Trier de Alemania. Esto es así ya que aunque se viese comprometido cualquiera de los
tokens descritos en la
RFC 6749 de
OAuth2, dichos
tokens sólo tendrían validez para los usuarios que autorizaron su emisión o para las aplicaciones autorizadas por el usuario para su uso.
Conclusiones
En este trabajo se ha descrito como un servidor de
OAuth2 sería capaz de mitigar los riesgos detectados a día de hoy, tanto a nivel formal contra la propia definición del protocolo, como contra las vulnerabilidades más frecuentes detectadas en las implementaciones más importantes de servidores de
OAuth2. Para ello, se ha propuesto un modelo de autenticación basada en riesgos utilizando mecanismos de identificación de cliente.
Además, también se ha propuesto una generación de
tokens autocontenidos de los que se podría recuperar la identidad del cliente para verificar que el
token fue presentado por el mismo usuario para el que fue emitido. Toda esta propuesta se ha llevado a cabo teniendo en cuenta el marco de la legalidad vigente en
España y la capacidad de gestionar la alta disponibilidad por parte de las implementaciones de servidores de
OAuth2 que desarrollen esta propuesta.
Autor: Elias Grande (@3grander) autor del Proyecto ODIN
Graduado en por el Master de Seguridad de la UEM
Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
