Mitigación de la suplantación de identidad en OAuth 2 0 Parte II de II
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
Sigue Un inform�tico en el lado del mal - Google+ RSS 0xWord
download file now
alternative link download