Header Ads Widget

Ticker

6/recent/ticker-posts

La API de su aplicación para iPhone NO es privada

 En preparación para el Nordic Tour , estamos explorando la gama de API públicas y privadas . Una parte muy importante de eso son las API para aplicaciones móviles. Una gran mayoría de las aplicaciones de iPhone que dependen de una API para comunicarse con un sistema de back-end, e incluso las aplicaciones más simples, a menudo usan una API de algún tipo. Al mismo tiempo, es muy fácil ver qué tráfico de red tiene lugar entre dicha aplicación móvil y el servidor. Esto permite a los desarrolladores externos ver cómo funciona la API de la aplicación, incluso si no está documentada. Esto significa que su API "privada" para su aplicación móvil es en realidad una API pública apenas velada.

Cómo interceptar el tráfico

Hay varias herramientas para hacer esto. El que prefiero es Charles Proxy , y bastante fácil de configurar. Este es un gran artículo sobre cómo hacerlo). Básicamente, enviará todo el tráfico hacia y desde su teléfono a través de un proxy en su computadora. Al instalar algunos certificados, Charles (u otras herramientas de proxy) también puede interceptar el tráfico cifrado SSL y mostrarlo como texto sin formato. SSL es bueno, pero en este caso no hace nada.

Ejemplo

Echemos un vistazo a un par de ejemplos. La primera es la aplicación de teléfono del aeropuerto de Copenhague . Una verificación rápida en Charles Proxy deja en claro que la aplicación solicita datos a través de un POST de cph.novasa.com/json-rpc/?service=cphdata con parámetros en el cuerpo de la solicitud y que están usando HTTP Digest para la autenticación.

cph-trafficsolicitud de CPH

Esto se puede hacer con cualquier aplicación móvil. Ya le ha pasado a Instagram , SJ, un operador de trenes sueco (en sueco), numerosos bancos, y otros.

Implicaciones de seguridad

La principal implicación es que "la seguridad a través de la ofuscación" es, como siempre, una mala idea. Especialmente cuando la ofuscación puede dejarse de lado en unos minutos. Tenga en cuenta que cualquiera puede ver cómo está diseñada su API, qué credenciales de API (claves de API, por ejemplo) utiliza y qué datos se envían de un lado a otro. Si la API realmente está manejando datos súper sensibles, probablemente no debería estar en una aplicación móvil para empezar.

Incluso si otros pueden ver el tráfico entre su teléfono y su servidor, eso no significa que los usuarios no autorizados puedan usar fácilmente su API. Evitar esto se reduce al esquema de seguridad de sus API. Si está utilizando claves API, HTTP Basic o similar, todas las credenciales estarán fácilmente disponibles. Por lo tanto, cualquiera puede usar sus claves para acceder a su API. La creación de un esquema de seguridad de API adecuado para evitar esto será uno de los temas en los que profundizaremos durante el recorrido. Los expertos en seguridad de Twobo y Axway estarán entre los que se presentarán para ayudar a arrojar algo de luz sobre este aspecto desafiante de las API.

¿Qué hacer con esto?

Lo primero que debe hacer es NO ENTRAR EN PÁNICO. Si la API de su aplicación "privada" se documenta en GitHub y la utilizan los desarrolladores, tiene una gran confirmación de que existe un mercado para una API pública. Es una investigación de mercado y debe tratarse como tal. Trate de ver la interceptación del tráfico como una oportunidad y no como una amenaza. Diseñe su API como si fuera pública incluso si solo planea usarla en su propia aplicación móvil.

La alternativa es optimizar su API privada para su propio caso de uso. Si hace esto, aún debe tener en cuenta que otros pueden usar su API. Si lo hacen y su aplicación se vuelve tremendamente popular, ¿realmente quieres romper su aplicación cambiando tu API privada? Quizás no, en cuyo caso puede encontrarse atascado en el soporte de una API menos que ideal.

Publicar un comentario

0 Comentarios