Coders Conquer Security Infrastructure as Code Series - Business Logic

Published Jun 22, 2020
by Matias Madou, Ph.D.
cASE sTUDY

Coders Conquer Security Infrastructure as Code Series - Business Logic

Published Jun 22, 2020
by Matias Madou, Ph.D.
View Resource
View Resource

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.


View Resource
View Resource

Author

Matias Madou, Ph.D.

Matias is a researcher and developer with more than 15 years of hands-on software security experience. He has developed solutions for companies such as Fortify Software and his own company Sensei Security. Over his career, Matias has led multiple application security research projects which have led to commercial products and boasts over 10 patents under his belt. When he is away from his desk, Matias has served as an instructor for advanced application security training courses and regularly speaks at global conferences including RSA Conference, Black Hat, DefCon, BSIMM, OWASP AppSec and BruCon.

Matias holds a Ph.D. in Computer Engineering from Ghent University, where he studied application security through program obfuscation to hide the inner workings of an application.

Want more?

Dive into onto our latest secure coding insights on the blog.

Our extensive resource library aims to empower the human approach to secure coding upskilling.

View Blog
Want more?

Get the latest research on developer-driven security

Our extensive resource library is full of helpful resources from whitepapers to webinars to get you started with developer-driven secure coding. Explore it now.

Resource Hub

Coders Conquer Security Infrastructure as Code Series - Business Logic

Published Jun 22, 2020
By Matias Madou, Ph.D.

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.


We would like your permission to send you information on our products and/or related secure coding topics. We’ll always treat your personal details with the utmost care and will never sell them to other companies for marketing purposes.

To submit the form, please enable 'Analytics' cookies. Feel free to disable them again once you're done.