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.
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
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://bit.ly/2CF45kI
URL de API de prueba http://bit.ly/2HBILA9
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://bit.ly/2CC3TCD
API versión 2 http://bit.ly/2HDpHSb
API versión 3 http://bit.ly/2CCaQ6P
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
- 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.
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://bit.ly/2ENbNz2
- 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.
- JSON Web Token (JWT):
La firma de JWT se calcula de la siguiente forma:
HMACSHA256(base64UrlEncode(header) + "." +base64UrlEncode(payload),secret);
- Otros:
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á
Artículo publicado en el Blog de ElevenPaths - Sucríbete al RSS - Sigue ElevenPaths en Twitter - Sitio web oficial de ElevenPaths
Tags : ElectronicLab ElevenPaths Blog IFTTT Nicaragua
Carlos Gutierrez
Seo Construction
Me gusta hacer diseños frescos y creativos. Mi alijo de diseños siempre está lleno de ideas refrescantes. No dude en echar un vistazo a mi Vcard.
- Carlos Gutierrez
- Februari 24, 1989
- 1220 Manado Trans Sulawesi
- contact@example.com
- +123 456 789 111
Publicar un comentario
Nota: sólo los miembros de este blog pueden publicar comentarios.