A menudo me preguntan por las API en la sombra y los parámetros de API en la sombra, incluso personas con mucha experiencia en el desarrollo de API. No es de extrañar, porque las API en la sombra no suelen ser un riesgo en el que se piense durante el desarrollo normal de una API. De hecho, algunas personas están convencidas de que las API en la sombra no son más que una táctica de miedo utilizada por los proveedores de seguridad para vender sus herramientas.
Sin embargo, en realidad, las API en la sombra son relativamente fáciles de construir y utilizar. ¿Cuál es la mejor manera de entenderlas mejor? Observando ejemplos reales. Eso es lo que trataremos en este artículo.
¿Qué son las API en la sombra?
Empecemos con este ejemplo de solicitud de API que he encontrado:
Esta es una petición a una API GraphQL para generar la contraseña de un solo uso (OTP) utilizada en la autenticación de un servicio web. Puede que no veas el problema si no te fijas bien, así que lo he marcado con una gran flecha roja. Ese otpDigit parámetro es en realidad un problema importante.
He descubierto que este parámetro se puede modificar a través de la API. Modificándolo, puedes ajustar la longitud de la contraseña de un solo uso requerida para la autenticación. ¿Cuáles son las implicaciones? Pude cambiar el valor a 1. De este modo, el número de posibilidades para la contraseña pasó de un millón a sólo 10.
Comprensiblemente, el equipo de desarrollo se alarmó cuando les hablé de este parámetro, y lo arreglaron enseguida. No obstante, este es un ejemplo perfecto de las API en la sombra y sus parámetros. Lo más probable es que este parámetro fuera una comodidad inicial del desarrollador utilizada para crear prototipos o realizar pruebas. Cuando la API pasó a producción, nunca se eliminó la compatibilidad con el parámetro, que se convirtió en un parámetro API en la sombra.
Sin alguien sondeando este punto final en particular para ver qué se podía hacer con un parámetro no documentado, no se habría descubierto esta importante vulnerabilidad. Y lo que es más importante, un equipo de desarrollo no buscará esto intensamente hasta que se le presente la vulnerabilidad.
Este ejemplo sienta las bases para una directriz de trabajo relativa a los puntos finales y parámetros de API en la sombra: Cualquiera de sus parámetros o puntos finales de API que no estén directamente en el punto de mira de los desarrolladores existen en las sombras, y presentan un riesgo porque el equipo de seguridad probablemente también los pasará por alto.
¿Qué puedo hacer con las API en la sombra?
Ahora que sabes qué son los parámetros y puntos finales de la API en la sombra, la siguiente pregunta es qué puedes hacer al respecto. Obviamente, no puedes simplemente decirle a tu equipo de seguridad que sea más vigilante, especialmente con respecto a aquellas cosas que los desarrolladores ni siquiera están destacando en su trabajo activo.
Lo más probable es que necesite una herramienta o un proceso que le ayude a evaluar la seguridad de sus API. El tipo de herramienta que necesite dependerá del tamaño de su empresa y del número de API que tenga desplegadas. Las pasarelas de API o incluso las herramientas de seguridad de API pueden ayudarle a tener el grado de seguridad que necesita, pero pueden ser más de lo que necesita. Si sólo tiene varios puntos finales disponibles para los consumidores de API, desplegar un conjunto robusto de herramientas que rastreen el tráfico a través de su pila y le alerten de actividades sospechosas es definitivamente una exageración.
Un enfoque más sencillo es asegurarse de que las API están bien documentadas. Este es también un buen punto de partida. Empiece por adoptar el estándar OpenAPI para documentar sus API. Recuerde que las APIs en la sombra nacen cuando no se presta atención a sus endpoints y parámetros. El objetivo del estándar OpenAPI es proporcionar un modelo para especificar -y, por tanto, conocer- cada punto final y parámetro de su API.
A partir de ahí, también puede exigir a sus desarrolladores que proporcionen esta documentación de la API al equipo de seguridad cuando realicen el despliegue. A continuación, el equipo de seguridad comprobará la API con la documentación para detectar cualquier imprecisión o laguna. Esto evitará cualquier punto ciego.
Conclusión
Las cosas no acecharán en las sombras si iluminas esos espacios. Al fin y al cabo, si conoces los detalles de las API que has desplegado, las API en la sombra no pueden existir. Aunque tal vez no sea la tarea más emocionante del mundo, documentar tus API te ayudará a evitar abrirlas a atacantes malintencionados.
Esperamos que este artículo le haya aclarado la definición y los peligros de las API en la sombra. Go ilumine los rincones oscuros de su infraestructura de API para evitar brechas de seguridad.
Comentarios