Serie Coders Conquer Security OWASP Top 10 API - Gestión inadecuada de activos

A diferencia de la mayoría de las vulnerabilidades del top diez de API de OWASP, la gestión inadecuada de activos no se centra específicamente en fallos de codificación. En cambio, esta vulnerabilidad es más un problema humano o de gestión que permite que las API antiguas permanezcan activas mucho después de que deberían haber sido reemplazadas por versiones más nuevas y seguras. También puede ocurrir si las API que aún están en desarrollo se exponen al entorno de producción antes de estar completamente protegidas contra amenazas.

Esta vulnerabilidad es particularmente difícil de gestionar debido a la llegada de los microservicios y la computación en la nube. En ese entorno, se pueden crear nuevos servicios rápidamente para satisfacer una necesidad temporal, para luego olvidarlos y nunca darlos de baja. Si las API antiguas permanecen conectadas al entorno de producción, pueden poner en peligro toda la red.

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

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

El fallo de gestión inadecuada de activos es un producto de los tiempos modernos. Las organizaciones que se mueven a la velocidad del negocio a veces pueden crear cientos o miles de servicios y microservicios cada día. Esto a menudo se hace rápidamente y sin crear documentación alguna, ni explicación sobre para qué se utilizan las API asociadas, cuánto tiempo serán necesarias o su nivel de criticidad. Esto puede generar rápidamente una proliferación de API que podría volverse incontrolable con el tiempo, especialmente si no existen políticas generales que definan cuánto tiempo pueden existir las API.

En ese entorno, es muy posible que algunas API 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 responsables. Por ejemplo, un grupo de marketing podría crear un servicio para ayudar a respaldar un próximo evento, como el lanzamiento de un producto, y luego nunca eliminarlo después de que el evento haya terminado. Alguien que observe ese servicio y sus API asociadas más tarde podría no tener idea de por qué existen y, si no hay documentación, podría seguir siendo un misterio. Es posible que no se sientan cómodos eliminando esas API del entorno de producción o incluso actualizándolas a versiones más nuevas porque no tienen idea de cuán críticas son o qué hacen.

La vulnerabilidad se vuelve peligrosa porque la seguridad de las API en los marcos de trabajo mejora con el tiempo. Un investigador podría descubrir una vulnerabilidad, o se podría añadir seguridad adicional para detener un tipo de ataque cada vez más popular. Las API antiguas pueden seguir siendo vulnerables a esos ataques a menos que se actualicen, por lo que los hackers a menudo las buscarán o utilizarán herramientas automatizadas para encontrarlas.

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

Un atacante notó que la ubicación de la nueva API era algo como (api.criticalservice.com/v2). Al reemplazar la URL con (api.criticalservice.com/v1), pudieron usar la API antigua con la vulnerabilidad conocida. Esto finalmente expuso los registros personales de más de 100 millones de usuarios.

Eliminación de los fallos de gestión inadecuada de activos

La única forma de eliminar el fallo de gestión inadecuada de activos de su entorno es mantener un inventario estricto de todas las API, sus usos y versiones. Esto debería comenzar con un inventario de las API existentes, centrándose en factores como en qué entorno deben implementarse (producción o desarrollo), quién debe tener acceso de red a ellas y, por supuesto, su versión.

Una vez completado esto, debe implementar un proceso donde la documentación se añada automáticamente a cualquier API o servicio nuevo que se cree. Esto debe incluir todos los aspectos de la API, incluyendo la limitación de tasa, cómo maneja las solicitudes y respuestas, el intercambio de recursos, a qué puntos finales puede conectarse, cualquier política relevante que se aplique, además de cualquier otra cosa que sea necesaria para auditarlas más adelante. También debe evitar usar API que no sean de producción o aquellas del entorno de desarrollo en producción. Considere también añadir un límite de tiempo a las API donde su uso continuado deba ser justificado por sus propietarios para evitar la baja automática.

Siempre que haya nuevas versiones de API activas disponibles, realice una evaluación de riesgos para determinar si debe actualizar y cómo debe llevarse a cabo ese proceso para evitar interrumpir el entorno de producción. Una vez que haya migrado a las nuevas API, elimine las antiguas por completo del entorno.

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

‍