Los programadores conquistan la infraestructura de seguridad como una serie de códigos - Business Logic

Bueno, esto es todo (por ahora). Hemos llegado al final de nuestra serie Infrastructure as Code. Esperamos que te hayas divertido solucionando los problemas de seguridad en Docker, Ansible, Kubernetes, Terraform y CloudFormation. Sin embargo, antes de cerrar sesión, tenemos una vulnerabilidad más que debes dominar: los errores de lógica empresarial.

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

Si aún no tienes claro algunas cosas, sigue leyendo:

Las vulnerabilidades en las que queremos centrarnos hoy son lógica empresarial defectos. Estas pueden ocurrir cuando los programadores no implementan correctamente las reglas de lógica empresarial, lo que podría hacer que sus aplicaciones fueran vulnerables a diferentes tipos de ataques en caso de que un usuario malintencionado decidiera explotarlas. Según la finalidad y la funcionalidad implementadas en cada aplicación, un fallo en la lógica empresarial puede permitir el aumento de privilegios, el uso inadecuado de los recursos o la ejecución de cualquier cantidad de procesos empresariales no deseados.

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

¿Cuáles son algunos ejemplos de fallas en la lógica empresarial?

Como ejemplo de lo fácil que puede ser inducir fallos en la lógica empresarial, considere el siguiente ejemplo de un entorno de Docker definido con un archivo de Docker Compose. Para preparar los contenedores para que ejecuten funciones, un desarrollador puede usar una política de recursos estándar, definida en el archivo Docker Compose, como en el ejemplo siguiente:

implementar:
recursos:
límites:
tazas: «0.5"
reservas:
tazas: «0.5"

Si bien esto parece correcto a primera vista, esta política de recursos para contenedores no limita adecuadamente el uso de los recursos. Un atacante podría aprovechar la falla de la lógica empresarial 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 admite cada contenedor. Por lo tanto, el nuevo código podría incluir una restricción de ubicación:

implementar:
recursos:
límites:
tazas: «0.5"
reservas:
tazas: «0.5"
colocación:
restricciones:
- «node.labels.limit_cpu == 100 M»
- «node.labels.limit_memory == 0.5"

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

Como puede ver, pensar en las fallas de la lógica empresarial y programar para eliminarlas puede ser una tarea difícil.

Eliminar las fallas de la lógica empresarial

Con las fallas de la lógica empresarial, la clave es saber que existen. Debe estar atento para mantenerlos fuera de su entorno mientras se escribe código nuevo. Las reglas empresariales y las mejores prácticas deben definirse y comprobarse claramente en todas las fases del proceso de desarrollo de la aplicación, incluidos el diseño, la implementación y las pruebas.

Por ejemplo, para evitar que una falla en la lógica empresarial permita un ataque DoS como en el ejemplo anterior, se recomienda limitar la cantidad de recursos que pueden usar todos los contenedores de Docker que crees. En concreto, la sección de límites debe especificar la cantidad de CPU y la cantidad de memoria que puede usar un contenedor Docker. Un ejemplo sería:

implementar:
recursos:
límites:
tazas: «0.5"
memoria: 100M
reservas:
tazas: «0.5"
memoria: 50 M

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

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

Las fallas de la lógica empresarial 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. Saber cómo pueden ocurrir y utilizar las mejores prácticas puede mantenerlos alejados de su entorno durante el desarrollo de las aplicaciones y garantizar que nunca lleguen a un entorno de producción en el que puedan abusar de ellos atacantes que están muy familiarizados con la forma de explotarlos.

Eche un vistazo a la Secure Code Warrior páginas de 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 otras fallas de seguridad. También puedes prueba una demo de este desafío de IaC en la plataforma de formación Secure Code Warrior para mantener todas sus habilidades de ciberseguridad perfeccionadas y actualizadas.