Les codeurs conquièrent l'infrastructure de sécurité en tant que série de codes - Business Logic

Well, this is it (for now). We have reached the end of our Infrastructure as Code series. We hope you've had fun conquering security issues in Docker, Ansible, Kubernetes, Terraform, and CloudFormation. Before we sign off, though, we've got one more vulnerability for you to master: business logic bugs.

Think you're ready to test your skills now? Try the final gamified challenge:

If you're still unclear on a few things, keep reading:

The vulnerabilities we want to focus on today are business logic flaws. These can occur when coders fail to properly implement business logic rules which could leave their applications vulnerable to different kinds of attacks should a malicious user choose to exploit them. Depending on the purpose and functionality implemented within each application, a business logic flaw may allow privilege escalation, improper resource usage or any number of unintended business processes to be performed.

Unlike many vulnerabilities, incorrect implementation of business logic rules can be surprisingly subtle. They require special vigilance to ensure that they don't sneak into applications and code.

What are some examples of business logic flaws?

As an example of how easy it can be to induce business logic flaws, consider the following example from a Docker environment defined with a Docker Compose file. To prepare containers to perform functions, a developer might use a standard resource policy, defined in the Docker Compose file,  like the following example:

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

While that looks fine on the surface, this resource policy for containers isn't properly limiting resource usage. An attacker could take advantage of the business logic flaw to implement a denial of service (DoS) attack.

To try and limit users from taking up too many resources, a developer might try to better define what each container can support. So the new code might include a placement constraint:

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

At first glance, this looks like it would resolve the business logic flaw. However, the new placement constraint does not affect the resource usage limit for the Docker container service. It's only used to select a node to schedule the container. In this case, a DoS attack is still possible. The attacker would need to compromise a Docker container first, but would be able to drain resources without limits after that.

As you can see, thinking about business logic flaws and programming to eliminate them can be a tricky endeavor.

Eliminating business logic flaws

With business logic flaws, the key is knowing that they exist. You need to be vigilant about keeping them out of your environment while new code is being written. Business rules and best practices should be clearly defined and checked at all phases of the application development process including design, implementation and testing.

For example, to prevent a business logic flaw from enabling a DoS attack like in the above example, a best practice is to limit the amount of resources that every Docker container you create can use. Specifically, the limits section must specify the number of CPUs and the amount of memory a Docker container can use. An example would be:

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

Using code like the example above as a policy would remove a major business logic flaw from the environment and prevent DoS attacks. This would work even if an attacker compromised one of the Docker containers. In that case, the attacker would still not be able to use their foothold to deplete resources.

Threat modeling can be helpful by defining how different attacks take place and ensuring that business logic rules are used to prevent and restrict them. Testing based on compliance rules and known abuse cases could also be helpful in catching business logic flaws that slip through the cracks.

Business logic flaws are some of the most subtle vulnerabilities that can sneak into applications, but are no less dangerous than other more high-profile risks. Knowing how they can occur and using best practices can keep them out of your environment during application development, ensuring that they never reach a production environment where they can be abused by attackers who are very familiar with how to exploit them.

Check out the Secure Code Warrior blog pages for more insight about this vulnerability and how to protect your organization and customers from the ravages of other security flaws. You can also try a demo of this IaC challenge in the Secure Code Warrior training platform to keep all your cybersecurity skills honed and up-to-date.