# La Seguridad en OAuth El protocolo OAuth 2.0 se utiliza mucho en las aplicaciones de terceros hoy en día. Ofrece una experiencia de usuario fluida y una autenticación y autorización más sencilla en comparación con los métodos tradicionales (nombre de usuario y contraseña).Los usuarios no tienen que compartir sus credenciales con la aplicación de terceros para acceder a un determinado recurso. Todos preferimos iniciar sesión con Google, Facebook o LinkedIn en lugar de crear una cuenta con nuevas credenciales cada vez que necesitamos registrarnos en un nuevo sitio web. El protocolo OAuth nos ha simplificado mucho la vida. ![](https://www.thesecuritybuddy.com/wordpress/bdr/uploads/2020/05/OAuth2.jpg.webp) Los proveedores de servicios OAuth más conocidos son muy fiables. Iniciar sesión con Google o Facebook puede darnos cierta sensación de seguridad, y con razón. El protocolo ha sido probado exhaustivamente, y las vulnerabilidades siempre se han parcheado con bastante rapidez. Pero esta sensación de seguridad puede ser falsa. La cuestión de la seguridad es un poco complicada. Los proveedores de servicios OAuth han dejado al desarrollador mucho que pensar. De hecho, un servicio OAuth seguro implementado de forma incorrecta por un desarrollador inconsciente puede conducir a grandes robos de datos. Las vulnerabilidades más comunes encontradas en las aplicaciones de terceros que implementan el protocolo OAuth para autorizar a sus usuarios.El protocolo en sí es seguro y fiable, su implementación puede ser vulnerable. ## Robo de Token OAuth a través de Referer Cuando tu aplicación solicita autorización al servidor OAuth en nombre de un usuario, el servidor OAuth devuelve un código a la aplicación web, este código se envía de nuevo al servidor OAuth para su verificación.La cabecera Referer es una cabecera en las peticiones HTTP que comunica al Host la URL desde la que se envía la petición. Si en el proceso el usuario es redirigido a otra página, el código será visible en la cabecera Referer de la petición HTTP. Por lo tanto, su código se filtrará a sitios web externos que comprometerán los recursos del usuario conectado en el servidor OAuth. Para mitigar esta vulnerabilidad, el desarrollador necesita asegurarse de que su aplicación web no contiene ningún tipo de inyección de html. Si lo hace, el atacante puede colocar una etiqueta de imagen en su servidor web y encontrar una manera de redirigir al usuario a ella. Entonces puede robar el código de la cabecera Referer de la petición. ## Robo del Token OAuth a través de redirect_uri Como hemos visto en la Introducción al protocolo OAuth, la aplicación inicia el proceso de autorización mediante una petición al servidor OAuth: ```html https://www.example.com/signin/authorize?[...]&redirect_uri=https://demo.example.com/loginsuccessful ``` La petición siempre contiene un parámetro redirect_uri que el servidor OAuth utiliza para devolver el token a la aplicación después de que el usuario haya dado su consentimiento. En caso de que los valores de este parámetro no estén controlados o verificados, un atacante puede modificar fácilmente este parámetro y redirigir la solicitud a su sitio web donde implementa un manejador para recibir el token y acceder al recurso restringido. ```html https://www.example.com/signin/authorize?[.`.]&redirect_uri=https://localhost.evil.com ``` A veces estas URI están bloqueadas. El atacante puede redirigir a una URL abierta aceptada como esta, ```html https://www.example.com/oauth20_authorize.srf?[...]&redirect_uri=https://accounts.google.com/BackToAuthSubTarget?next=https://evil.com ``` ` o ```hmtl https://www.example.com/oauth2/authorize?[...]&redirect_uri=https%3A%2F%2Fapps.facebook.com%2Fattacker%2F ``` Las implementaciones de OAuth nunca deben poner en la lista blanca dominios al completo, sólo algunas URLs para que "redirect_uri" no pueda apuntar a un Open Redirect.