# Improper Authentication - **Autenticacion** La gestion de sesion y autenticacion constituyen los componentes principales de las aplicaciones web modernas. La autenticacion le permite a los usuarios a ganar acceso a las aplicaciones web, mediante la verificacion de sus entidades. La forma mas comun de autenticacion es usando un mecanismo de usuarios y contraseñas. Un usuario introduciria sus credenciales y el servidor le verificara. Si son correctas, el servidor le permitira navegar por la web, con una cookie de sesion. Una cookie de sesion es necesaria porque los servidores web utilizan HTTP/HTTPS para comunicarse los cuales no tienen estado. Atachear la cookie de sesion significa que el servidor, sabra quien esta enviando los datos. El servidor puede tener un seguimiento de las acciones de los usuarios. Si un atacante es capaz de encontrar vulnerabilidades en el mecanismo de autenticacion, entonces podria ganar acceso a la cuenta de otro usuario. Permitiendole al usuario acceder a datos sensibles. Algunas vulnerabilidades comunes son: * Ataques De Fuerza Bruta: Si una aplicacion web utiliza usuarios y contraseña, un usuario es capaz de lanzar un ataque de fuerza bruta, lo que le permite es adivinar el usuario y la contraseña usando multiples intentos de autenticacion. * Uso de credenciales debiles: Las aplicaciones web deberian tener unas politicas para credenciales mas robustas: Si la aplicacion permite utilizar contraseñas como "password1" o contraseñas comunes, entonces un atacante seria capaz de adivinarlas facilmente y ganar acceso a las cuentas de los usuarios. No hace falta fuerza bruta, se puede hacer manualmente * Cookies De Sesion Debiles: Las cookies de sesion son los que permite al servidor mantener un seguimiento del usuario. Si la cookie de sesion contiene valores predecibles, un atacante puede usar su propia cookie de sesion y acceder a las cuentas de los usuarios ## OAuth 2.0 Authentication Vulnerabilities ![](https://i.imgur.com/b72UrHH.png) - **Que es OAuth 2.0?** OAuth 2.0 es un framework muy popular el cual permite a las aplicaciones web a dar un acceso limitado a un usuario. Crucialmente, OAuth permite a un usuario a garantizar su acceso sin exponer las credenciales de login a la aplicacion que estan solicitando. Esto significa que los usuarios pueden afinar que datos quieren compatir en vez de dejar todos los datos de su cuenta a un tercero. - **Como funciona OAuth 2.0?** OAuth 2.0 fue originalmente creado como una manera de compartir acceso a aplicaciones especificas. Funciona definiendo una serie de interacciones entre tres diferentes partes: * Aplicacion Del Cliente: La pagina web, que quiere acceder a los datos de los usuarios * Propietario del Recurso: El usuario a cuyos datos quiere acceder la aplicacion cliente * Proveedor de servicios OAuth: La aplicacion web o la aplicacion que controla los datos del usuario y acceder a el. Ellos apoyan a OAuth proporcionando una API para interactuar tanto con un servidor de autorizacion como un servidor de recursos. Estos son los pasos que sigue la autorizacion OAuth: 1 - La aplicacion del cliente pide acceso a un subset de los datos del usuario, especificando que datos quieren usar y a cuales quieren acceder. 2 - El usuario es redirigido al log in en el servicio OAuth y explicitamente le dan permiso a los accesos que han solicitado 3 - La aplicacion del cliente recibe un token de acceso unico, que prueba que el usuario tiene permisos para acceder a los datos que ha solicitado. 4 - La aplicacion del cliente usa este access token para hacer llamadas a la API buscando los datos relevantes desde el resource server. - **OAuth Authentication** Para los mecanismos de autenticacion de OAuth, el basic flow de OAuth se mantiene igual; la principal diferencia es como la aplicacion del cliente usa los datos que recibe. Desde una perspectiva end-user, el resultado de una autenticacion OAuth es algo que se parece a SSO. La autenticacion OAuth normalmente es implementada tal que asi: 1 - El usuario escoje la opcion para logearse con una de sus cuentas de sus redes sociales. La aplicacion del cliente despues utiliza el sitio web de la red social, el servicio OAuth pide acceder a algunos datos para identificar al usuario 2 - Despues de recibir el token, la aplicacion del cliente, pide datos a este servidor, tipicamente desde un endpoint /userinfo 3 - Una vez que ha recibido los datos, la aplicacion del cliente usa en su lugar, el usuario para logearse. El access token que recibe de el servidor de autorizacion es normalmente usado en vez de una contraseña tradicional - **Identificando una Autenticacion OAuth** Reconocer cuando una aplicacion esta usando una autenticacion OAuth es relativamente siempre lo mismo. Si ves una opcion de log usando una cuenta de otra pagina web, esto es una indicacion de que se esta utilizando el OAuth. La mejor manera de identificar una autenticacion OAuth es proxear tu trafico con burpsuite y chequear los correspondientes mensajes HTTP cuando usas esta opcion de login. El primer tipo de request que siempre saldra es al endpoint /authorization contiendo un numero de querys que son especificamente usados para OAuth. En particular, tendremos muy en cuenta el client_id, redirect_uri y el response_type. Por ejemplo, una peticion de autorizacion se vera asi: ``` GET /authorization?client_id=12345&redirect_uri=https://client-app.com/callback&response_type=token&scope=openid%20profile&state=ae13d489bd00e3c24 HTTP/1.1 Host: oauth-authorization-server.com ``` * Proteccion CSRF defectuosa Aunque muchos componentes del flujo de OAuth son opcionales, hay algunos que son extremadamente recomendados, a no ser que haya una razon de peso para no usarlos. Un ejemplo es el parametro ```state``` El parametro ```state``` contiene un valor ungueseable, como por el ejemplo el hash de algo que va ligado con la sesion del usuario cuando inicia el flow OAuth. Este valor es pasado para detras y para alante con la aplicacion cliente, y el servicio OAuth como una forma de token CSRF para el cliente de la aplicacion. Si te das cuenta de que la autorizacion no envia el parametro ```state``` , esto es extremadamente interesante desde la perspectiva de un atacante. Esto significa potencialmente que ellos pueden iniciar un flujo OAuth por si mismos, antes de que el navegador de el usuario lo complete, esto es similar al ataque tradicional CSRF. Esto puede tener severas consecuencias dependiendo en como el OAuth este siendo utilizado en la aplicacion cliente. #### Mitigations - Para evitar el password guessing attacks, establecer una politica de contraseñas robustas - Para evitar ataques de fuerza bruta, se puede establecer un lockout automatico, despues de un cierto numero de intentos - Implementar un 2FA si un usuario tiene multiples metodos de autenticacion, por ejemplo, usando un usuario y una contraseña y recibir un codigo en su telefono movil, esto pondria las cosas mas complicadas al - Para prevenir vulnerabilidades de OAuth, es esencial para el proveedor de OAuth tanto como la aplicacion cliente, a implementar una validacion robusta de las keys, especialmente el parametro redirect_uri.