Serie de Coders Conquer Security sobre Infraestructura como Código: Lógica de Negocio

Bueno, esto es todo (por ahora). Hemos llegado al final de nuestra serie sobre Infraestructura como Código. Esperamos que te hayas divertido superando problemas de seguridad en Docker, Ansible, Kubernetes, Terraform y CloudFormation. Sin embargo, antes de despedirnos, tenemos una vulnerabilidad más para que domines: los errores de lógica de negocio.

¿Crees que estás listo para poner a prueba tus habilidades ahora? Intenta el desafío gamificado final:

Si todavía tienes dudas sobre algunos puntos, sigue leyendo:

Las vulnerabilidades en las que queremos centrarnos hoy son los fallos de lógica de negocio. Estos pueden ocurrir cuando los programadores no implementan correctamente las reglas de lógica de negocio, lo que podría dejar sus aplicaciones expuestas a diversos tipos de ataques si un usuario malintencionado decide aprovecharlas. Dependiendo del propósito y la funcionalidad implementada en cada aplicación, un fallo de lógica de negocio puede permitir la escalada de privilegios, el uso inadecuado de recursos o la ejecución de cualquier cantidad de procesos de negocio no deseados.

A diferencia de muchas vulnerabilidades, la implementación incorrecta de las reglas de lógica de negocio puede ser sorprendentemente sutil. Requieren una vigilancia especial para garantizar que no se cuelen en las aplicaciones y el código.

¿Cuáles son algunos ejemplos de fallos de lógica de negocio?

Como ejemplo de lo fácil que puede ser inducir fallos de lógica de negocio, considera el siguiente caso de un entorno Docker definido con un archivo Docker Compose. Para preparar los contenedores para realizar funciones, un desarrollador podría utilizar una política de recursos estándar, definida en el archivo Docker Compose, como en el siguiente ejemplo:

deploy:
 resources:
   limits:
     cpus: "0.5"
   reservations:
     cpus: "0.5"

Aunque parece correcto a simple vista, esta política de recursos para contenedores no limita adecuadamente el uso de los mismos. Un atacante podría aprovechar este fallo de lógica de negocio para implementar un ataque de denegación de servicio (DoS).

Para intentar evitar que los usuarios consuman demasiados recursos, un desarrollador podría intentar definir mejor lo que cada contenedor puede soportar. Por lo tanto, el nuevo código podría incluir una restricción de ubicación:

deploy:
 resources:
   limits:
     cpus: "0.5"
   reservations:
     cpus: "0.5"
   placement:
     constraints:
       - "node.labels.limit_cpu == 100M"
       - "node.labels.limit_memory == 0.5"

A primera vista, parece que esto resolvería el fallo de lógica de negocio. Sin embargo, la nueva restricción de ubicación no afecta al límite de uso de recursos del servicio de contenedores Docker. Solo se utiliza para seleccionar un nodo donde programar el contenedor. En este caso, un ataque DoS sigue siendo posible. El atacante necesitaría comprometer primero un contenedor Docker, pero después podría agotar los recursos sin límites.

Como puedes ver, pensar en los fallos de lógica de negocio y programar para eliminarlos puede ser una tarea complicada.

Eliminación de fallos de lógica de negocio

Con los fallos de lógica de negocio, la clave es saber que existen. Debes estar atento para mantenerlos fuera de tu entorno mientras se escribe código nuevo. Las reglas de negocio y las mejores prácticas deben estar claramente definidas y verificadas en todas las fases del proceso de desarrollo de la aplicación, incluyendo el diseño, la implementación y las pruebas.

Por ejemplo, para evitar que un fallo de lógica de negocio permita un ataque DoS como en el ejemplo anterior, una buena práctica es limitar la cantidad de recursos que puede utilizar cada contenedor Docker que crees. Específicamente, la sección de límites debe especificar el número de CPU y la cantidad de memoria que puede usar un contenedor Docker. Un ejemplo sería:

deploy:
 resources:
   limits:
     cpus: "0.5"
     memory: 100M
   reservations:
     cpus: "0.5"
     memory: 50M

Utilizar código como el del ejemplo anterior como política eliminaría un fallo importante de lógica de negocio del entorno y evitaría ataques DoS. Esto funcionaría incluso si un atacante comprometiera uno de los contenedores Docker. En ese caso, el atacante aún no podría utilizar su punto de apoyo para agotar los recursos.

El modelado de amenazas resulta útil para definir cómo ocurren los distintos ataques y garantizar que se apliquen reglas de lógica de negocio para prevenirlos y restringirlos. Realizar pruebas basadas en normas de cumplimiento y casos de abuso conocidos también ayuda a detectar fallos de lógica de negocio que pasan desapercibidos.

Los fallos de lógica de negocio son algunas de las vulnerabilidades más sutiles que pueden infiltrarse en las aplicaciones, pero no son menos peligrosas que otros riesgos más conocidos. Comprender cómo se producen y aplicar las mejores prácticas permite evitarlos durante el desarrollo, asegurando que nunca lleguen a un entorno de producción donde puedan ser explotados por atacantes expertos.

Visita las páginas del blog de Secure Code Warrior para obtener más información sobre esta vulnerabilidad y cómo proteger a tu organización y a tus clientes de otros fallos de seguridad. También puedes solicitar una demostración de este desafío de IaC en la plataforma de formación de Secure Code Warrior para mantener tus habilidades de ciberseguridad al día.