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

¿Crees que ya estás preparado para poner a prueba tus habilidades? Prueba el último desafío gamificado:

Si todavía no tienes claras algunas cosas, sigue leyendo:

Las vulnerabilidades en las que queremos centrarnos hoy son los fallos de lógica de negocio. Estos pueden ocurrir cuando los codificadores no implementan adecuadamente las reglas de lógica de negocio que podrían dejar sus aplicaciones vulnerables a diferentes tipos de ataques si un usuario malicioso decide explotarlos. Dependiendo del propósito y la funcionalidad implementada dentro de cada aplicación, un fallo de lógica de negocio puede permitir la escalada de privilegios, el uso inadecuado de recursos o cualquier número de procesos de negocio no deseados.

A diferencia de muchas vulnerabilidades, la implementación incorrecta de 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 en la lógica empresarial?

Como ejemplo de lo fácil que puede ser inducir fallos en la lógica de negocio, considere el siguiente ejemplo 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 el siguiente ejemplo:

desplegar:
recursos:
límites:
cpus: "0.5"
reservas:
cpus: "0.5"

Aunque a primera vista parece que está bien, esta política de recursos para contenedores no está limitando adecuadamente el uso de recursos. Un atacante podría aprovechar el fallo de la lógica de negocio para implementar un ataque de denegación de servicio (DoS).

Para intentar limitar que los usuarios ocupen demasiados recursos, un desarrollador podría intentar definir mejor lo que puede soportar cada contenedor. Así, el nuevo código podría incluir una restricción de colocación:

desplegar:
recursos:
límites:
cpus: "0.5"
reservas:
cpus: "0.5"
colocación:
restricciones:
- "node.labels.limit_cpu == 100M"
- "node.labels.limit_memory == 0.5"

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

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

Eliminación de los fallos de la lógica empresarial

Con los defectos de la lógica de negocio, la clave es saber que existen. Hay que estar atento para mantenerlos fuera del entorno mientras se escribe el nuevo código. Las reglas de negocio y las mejores prácticas deben estar claramente definidas y comprobadas 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 el del ejemplo anterior, una buena práctica es limitar la cantidad de recursos que puede utilizar cada contenedor Docker que se cree. Específicamente, la sección de límites debe especificar el número de CPUs y la cantidad de memoria que un contenedor Docker puede utilizar. Un ejemplo sería:

desplegar:
recursos:
límites:
cpus: "0.5"
memoria: 100M
reservas:
cpus: "0.5"
memoria: 50M

El uso de un código como el del ejemplo anterior como política eliminaría un importante fallo de lógica empresarial del entorno y evitaría los ataques DoS. Esto funcionaría incluso si un atacante comprometiera uno de los contenedores Docker. En ese caso, el atacante seguiría sin poder utilizar su punto de apoyo para agotar los recursos.

El modelado de amenazas puede ser útil al definir cómo se producen los diferentes ataques y garantizar que se utilicen reglas de lógica empresarial para prevenirlos y restringirlos. Las pruebas basadas en las reglas de cumplimiento y los casos de abuso conocidos también podrían ser útiles para detectar los fallos de la lógica empresarial que se escapan.

Los fallos en la lógica de negocio son algunas de las vulnerabilidades más sutiles que pueden colarse en las aplicaciones, pero no son menos peligrosas que otros riesgos más destacados. Conocer cómo pueden producirse y utilizar las mejores prácticas puede mantenerlos fuera de su entorno durante el desarrollo de la aplicación, asegurando que nunca lleguen a un entorno de producción donde puedan ser abusados por atacantes que están muy familiarizados con la forma de explotarlos.

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 puedes probar una demostración de este desafío de IaC en la plataforma de formación Secure Code Warrior para mantener todos tus conocimientos de ciberseguridad perfeccionados y actualizados.