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.
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:
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.
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.
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.
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.
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:
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
 |
| 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.
 |
| Figura 13: Ley de Servicios de la Sociedad de la Información |
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.
 |
| Figura 14: Estándar JWT |
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.
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.
 |
| Figura 15: Técnicas de Web-based Device Fingerprinting |
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.
 |
| Figura 16: Cross-Browser Fingerprinting via OS and HW Level Features |
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.
 |
| Figura 19: Client Impersonation en OAuth 2.0 |
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.
 |
| Figura 21: JSON Web Token |
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.
 |
| Figura 22: OAuth 2.0 Token Introspection |
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.
 |
| Figura 23: Par´metros state en JWT de OAuth 2.0 |
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.
 |
| Figura 26: JSON Web Encryption (JWE) |
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
No entiendo nothing... Pero te apoyo de todos modos.
ResponderEliminar¿Cuando darás una conferencia en Argentina? Tenemos Asado y Fernet
Excelentes estos dos post sobre seguridad en Oauth 2.0
ResponderEliminar