it-swarm-es.com

Errores de usar OAuth para aplicaciones móviles

OAuth es una solución de autorización popular para aplicaciones web y aplicaciones móviles.

Cuáles son las desventajas de usar OAuth están en esos dos escenarios (como una aplicación web que proporciona OAuth acceso a la información de mis usuarios a otros sitios web, y también proporciona acceso a aplicaciones móviles (p. ej., Android, iOS).

24
Rory McCune

Bueno, la primera consideración es que SSL/TLS es absolutamente necesario para implementar correctamente.

También se deben considerar los mecanismos de autenticación de 2 o 3 patas. Si bien la mayoría recomendará el más complejo (y seguro) enfoque de 3 patas , es posible que 2 patas tenga ventajas cuando se hace correctamente para ciertas aplicaciones.

Ha habido algunos descubrimientos de ataques de tiempo en OAuth realizados por rootlabs . También hay riesgos de XSS/CSRF y ClickJacking (y otros ataques contra el authn), al igual que en cualquier aplicación web.

ArsTechnica publicó dos artículos sobre Arquitectura de seguridad de OAuth , uno vinculado desde Bruce Schneier .

10
atdre

El mayor problema con OAuth 1.0a en aplicaciones móviles y de escritorio es que la clave de consumidor/aplicación y el secreto de consumidor/aplicación, que se utilizan para firmar las solicitudes, se pueden extraer y exponer públicamente.

Por ejemplo, si eres proveedor de datos y creas y le das una clave de consumidor a otra aplicación web de terceros que desea acceder a los datos de tus usuarios, la clave y el secreto siempre estarán ocultos en el servidor web de terceros. Se supone que nadie tiene acceso a ellos (excepto algunos administradores de sistemas o desarrolladores). Pero esta clave no está expuesta públicamente al mundo.

Sin embargo, en el caso de aplicaciones móviles o de escritorio, los usuarios finales deben descargar estas aplicaciones a su teléfono/computadora. Por lo tanto, cualquier hacker puede descargar la aplicación y extraer el par clave/secreto del programa. En consecuencia, puede crear una aplicación maliciosa que finge ser la aplicación original del consumidor.

Este es, con mucho, el problema más grave de OAuth que conozco, al menos en la versión 1.0a del protocolo. El problema no es tan grave, ya que los usuarios finales aún tendrán que aprobar el acceso a la aplicación maliciosa y depende de ellos ver que tiene un nombre diferente y que puede sospechar sobre el ACCESO que desea. Sin embargo, cuando usted, como proveedor, espera tener consumidores móviles, nunca debe confiar en que ellos sean los que dicen que son.

En cuanto a los ejemplos anteriores de ATDRE, no creo que tenga que preocuparse demasiado, porque estos artículos presentan algunos escenarios hipotéticos y no dicen nada concreto sobre los defectos de OAuth. OAuth 1.0a es perfectamente seguro como protocolo si se realiza a través de SSL. Los ataques de los que hablan son solo ejemplos comunes de piratería web, que no tiene nada que ver con OAuth.

Por ejemplo, si alguien roba la cookie del usuario final, por supuesto, puede iniciar sesión y aprobar solicitudes en nombre del usuario ... pero esto no es un problema de OAuth. O el ejemplo de tiempo, que es un ejemplo de una implementación de biblioteca particular del protocolo, no con el protocolo en sí ...

Lamento no poder decirle detalles sobre OAuth 2.0, porque todavía no he implementado esa versión, sin embargo, puedo decirle que la versión 1.0a del protocolo es buena desde el punto de vista de la seguridad ...

5
luben

No tengo suficientes puntos para hacer un comentario, así que agregué esto como respuesta. OAuth es, en primer lugar, un protocolo de autorización y no principalmente una autenticación. Aunque la autenticación está integrada en el protocolo, no es el propósito principal.

5
smiley