A diferencia de la mayoría de las vulnerabilidades del top ten de APIs de OWASP, la gestión inadecuada de activos no se centra específicamente en defectos de codificación. En cambio, esta vulnerabilidad es más bien un problema humano o de gestión que permite que las APIs más antiguas sigan vigentes mucho tiempo después de que deban ser reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las APIs que todavía están en desarrollo se exponen al entorno de producción antes de que estén completamente reforzadas contra las amenazas.

Esta vulnerabilidad es especialmente difícil de gestionar debido a la llegada de los microservicios y la computación en nube. En ese entorno, los nuevos servicios pueden ponerse en marcha rápidamente para satisfacer una necesidad temporal y luego olvidarse de ellos y no retirarlos nunca. Si las APIs más antiguas se dejan conectadas al entorno de producción, se puede poner en peligro toda la red.

¿Quieres probar un desafío gamificado sobre este fallo de seguridad? Entra en nuestra arena: [Empieza aquí]

¿Cómo afectan los fallos de gestión de activos a las APIs?

El defecto de la gestión de activos inadecuados es un producto de los tiempos modernos. Las organizaciones que se mueven a la velocidad del negocio pueden a veces poner en marcha cientos o miles de servicios y microservicios cada día. Esto se hace a menudo rápidamente y sin la creación de ninguna documentación de acompañamiento, ni ninguna explicación de para qué se utilizan las APIs asociadas, cuánto tiempo se necesitarán o su criticidad. Esto puede generar rápidamente una proliferación de APIs que podría volverse incontrolable con el tiempo, especialmente si no hay políticas generales para definir cuánto tiempo pueden existir las APIs.

En ese entorno, es muy posible que algunas APIs se pierdan, se olviden o nunca se den de baja.

Los usuarios con permiso para crear nuevos servicios fuera del proceso normal también son a veces culpables. Por ejemplo, un grupo de marketing puede crear un servicio para apoyar un evento próximo, como el lanzamiento de un producto, y luego no retirarlo una vez finalizado el evento. Alguien que vea ese servicio y sus APIs asociadas más tarde podría no tener ni idea de por qué existen, y si no hay documentación, podría seguir siendo un misterio. Puede que no se sientan cómodos eliminando esas APIs del entorno de producción o incluso actualizándolas a versiones más nuevas porque no tienen ni idea de lo críticas que son o de lo que hacen.

La vulnerabilidad se vuelve peligrosa porque la seguridad de las APIs en los frameworks mejora con el tiempo. Un investigador puede descubrir una vulnerabilidad, o se puede añadir seguridad adicional para detener un tipo de ataque cada vez más popular. Las APIs más antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los hackers suelen buscarlas o utilizar herramientas automatizadas para buscarlas.

En un ejemplo del mundo real proporcionado por OWASP, una empresa actualizó sus APIs utilizadas para buscar en bases de datos de usuarios para parchear un fallo crítico. Pero dejaron las antiguas APIs en su lugar por error.

Un atacante se dio cuenta de que la ubicación de la nueva API era algo así como (api.criticalservice.com/v2). Reemplazando la URL por (api.criticalservice.com/v1) pudieron utilizar la antigua API con la vulnerabilidad conocida. Esto finalmente expuso los registros personales de más de 100 millones de usuarios.

Eliminación de los defectos de gestión de activos inadecuados

La única manera de eliminar el defecto de gestión de activos inadecuados de su entorno es mantener un inventario estricto de todas las APIs, sus usos y versiones. Esto debe comenzar con un inventario de las APIs existentes, centrándose en factores como el entorno en el que deben desplegarse, como producción o desarrollo, quién debe tener acceso a la red y, por supuesto, su versión.

Una vez que se haya completado, es necesario implementar un proceso en el que la documentación se añada automáticamente a cualquier nueva API o servicio que se cree. Esto debería incluir todos los aspectos de la API, incluyendo la limitación de la tasa, cómo maneja las solicitudes y las respuestas, los recursos compartidos, los puntos finales a los que se puede conectar, cualquier política relevante que se aplique, además de cualquier otra cosa que sea necesaria para auditarlas posteriormente. También hay que evitar utilizar nunca en producción APIs que no sean de producción o del entorno de desarrollo. Considera también la posibilidad de añadir un límite de tiempo a las APIs en el que su uso continuado deba ser justificado por sus propietarios para evitar el desmantelamiento automático.

Siempre que estén disponibles nuevas versiones de las APIs activas, realice un riesgo assessment para determinar si debe actualizar, y cómo debe llevarse a cabo ese proceso para evitar la interrupción del entorno de producción. Una vez que hayas migrado a las nuevas APIs, elimina las antiguas por completo del entorno.

Hacer todo esto puede ayudar a evitar que la vulnerabilidad de la gestión de activos inadecuada perjudique a su organización, a los usuarios o a la red. Consulte las páginas del Secure Code Warrior páginas del blog para obtener más información sobre esta vulnerabilidad y sobre cómo proteger a su organización y a sus clientes de los estragos de otros fallos de seguridad. También puede probar una demostración de la plataforma de formación Secure Code Warrior para mantener todos sus conocimientos de ciberseguridad perfeccionados y actualizados.

‍