Conectándonos al mundo (Parte1)

Sin duda alguna, las API (Interfaces de Programación para interconexión de Aplicaciones, sistemas, servicios) son de uso cotidiano y muchos desarrolladores brindan acceso a determinadas funcionalidades o características de sus proyectos a través de ellas. Sin embargo, ¿hay que preocuparse por la seguridad de ellas?

Introducción a la seguridad en API

Como sabemos, las API son aplicaciones intermediarias accedidas por internet que permiten a una aplicación comunicarse con otra. Las API implementan funciones, rutinas, procedimientos, obtienen información a partir de parámetros y devuelven información. En función de los parámetros que le envía el cliente, generalmente acceden a servicios y bases de datos que están en el backend, hacen llamadas a procedimientos o procesan algún tipo de rutina que permite ejecutar una lógica de negocio. Además de estos usos, las API están ampliamente difundidas en aplicaciones móviles e IoT (Internet of Things).

API utilizadas para gestionar cloud, por ejemplo, Amazon EC2

IEEE desarrolló un framework basado en API para IoT

En nuestro blog de ElevenPaths podrás encontrar información sobre el API de Latch.

Descubrir cómo funciona una API

A diferencia de otros tipos de interface, cuando se utiliza una API se requiere poseer la documentación de la misma, que permite conocer su forma de uso, verbos y funcionalidades disponibles.

Ejemplo de documentación de una API

Entonces, cuando comenzamos a evaluar la seguridad de una API, una de las primeras actividades es conseguir la documentación asociada a la misma. Generalmente esta documentación está destinada a los programadores y permite integrar sus aplicaciones con otros sistemas a través del uso de la API. En la documentación se puede brindar información como:

Lenguajes de desarrollo utilizados
Versión
Cómo funciona
Mensajes que se pueden enviar
Parámetros hay que enviar
Cómo es la autenticación
End-points, es decir, la URL a la cual conectarse. Por ejemplo api.twitter.com
Mensajes de error
Resultados devueltos

Estos datos son muy valiosos para poder tener un mejor entendimiento acerca de qué tipo de pruebas llevar adelante y cómo realizarlas.

End-point para pruebas

En general, las empresas que exponen API, brindan la posibilidad de realizar pruebas a medida que vamos desarrollando en nuestro software, para no hacerlo directamente en el ambiente productivo.

URL de API de producción http://api.twitter.com

URL de API de prueba http://developer.twitter.com

EndPoints

Estos end-points nos darán la posibilidad de conocer en detalle su funcionamiento. Muchas veces, la seguridad implementada en las diferentes aplicaciones no es la misma que en el ambiente de producción. Un ataque exitoso contra el end-point de prueba podría permitir al atacante ejecutar código arbitrario en servidores, lograr acceso o conseguir información privilegiada o de autenticación.

Versionado de la API

A medida que una aplicación va evolucionando y brindando mayor cantidad de servicios, o cuando se detectan fallas en la API, se van generando nuevas versiones de la API, las cuales incluyen más funcionalidades, servicios, mensajes o mejoras en su funcionamiento. Esto lo podemos encontrar por ejemplo de la siguiente forma:

API versión 1 http://www.sitio.com/api/v1

API versión 2 http://www.sitio.com/api/v2

API versión 3 http://www.sitio.com/api/v3

Versión de API

Sin embargo, podemos observar que, a medida que la API va evolucionando y generando actualizaciones, las versiones anteriores continúan estando presente en el sitio, ya sea por compatibilidad, por necesidades funcionales o por error.

Por ejemplo, para una aplicación determinada, podríamos leer la documentación y encontrar que la versión actual es la 4 y que para poder accederla se debe ingresar aquí.

Pero, cuando comenzamos a buscar, observamos que, si en el browser cambiamos el número por “v3”, la misma todavía existe. Recordemos que las actualizaciones de las versiones se producen porque las anteriores tenían alguna debilidad de seguridad.

Versión obsoleta publicada de la API

Lenguajes de programación de la API

Conocer con qué lenguaje está desarrollada la API también nos permitirá definir ataques específicos basados en esta información. Algunas formas de conseguir información sobre el lenguaje podrían ser:

Buscar en fuentes públicas de empleos o redes sociales profesionales. En este tipo de sitios encontraremos ofertas laborales buscando programadores para desarrollo de API en algún lenguaje en particular, con manejo de una base de datos en particular, etc. (OSINT)
Conectándonos al servidor y revisando los headers de respuesta, también podremos obtener información sobre qué lenguajes se podrían estar

La autenticación puede realizarse a través de varios métodos.

Basic Authentication:

Cuando el cliente se conecta a la aplicación que requiere este tipo de autenticación, la misma responde con un código HTTP 401, el cual simplemente significa “Autorización requerida”. Entonces el cliente debe enviar sus credenciales codificadas en Base64, base64encode(usuario:password) en unos de los HTTP headers del próximo request.

Authorization: YWRtaW46YWRtaW4=  admin:admin

En el siguiente ejemplo podemos ver cómo utilizando CURL podemos hacer una llamada utilizando basic authentication:

curl -u username:password’ -d «status=i%20am%20human» http://example.com/statuses/update.json

Digest Authentication:

La autenticación de tipo digest soluciona el problema de la transferencia de contraseñas en claro sin la necesidad de utilizar SSL o TLS. En el sistema se intercambian hashes en base al timestamp generado por el servidor en el momento de la petición, lo que lo hace más difícil de decodificar y por lo tanto más seguro.

curl –digest –user username:secret http://example.com/

JSON Web Token (JWT):

JSON web token (JWT) es un estándar abierto descripto en la RFC 7517 basado en JSON, es un contenedor con datos referentes a la autenticación. Los JWT utilizan un tipo de hash llamado HMAC, que son hashes generados con una llave privada.

La firma de JWT se calcula de la siguiente forma:

HMACSHA256(base64UrlEncode(header) + «.» +base64UrlEncode(payload),secret);

Otros:

Hay servicios que brindan mecanismos de autenticación a terceros (por ejemplo oAuth y Auth0), por lo cual nos tocará conocer también ese otro servicio y cómo el mismo es integrado e implementado en el sistema del cliente.

La forma de ver esto también podría ser utilizando la documentación pública de la API o bien, conectándonos a la misma y realizando un debug para ver qué tipo de autenticación se solicita.

Una vez que hayamos realizados estas actividades, tendremos un conocimiento más detallado de cómo funciona la API, qué recursos utiliza, cuáles son los lenguajes de desarrollo utilizados, cómo se gestiona el versionado, URL para realizar pruebas, URL de producción, mecanismos de autenticación y mucho más. Básicamente hemos realizado tareas de Fingerprinting, y ello nos permitirá también comprender cómo la organización gestiona la seguridad de las aplicaciones, y si hay seguridad definida dentro del ciclo de vida de desarrollo de software.

Los próximos pasos serán definir las pruebas que realizaremos a la API, pero eso lo dejaremos para la siguiente entrada.

Fabián Chiera

Chief Security Ambassador en Panamá

fabian.chiera@global.11paths.com

@fabianchiera

¿Cómo podría sobrevivir hoy una pyme como Dunder Mifflin?Cómo gestionar mejor las flotas de vehículos con herramientas Big Data