Although coding issues may be part of the problem, business logic errors are most frequently a result of design flaws or incorrect logical assumptions when an app is first created.
Unlike most of the other vulnerabilities we have covered in this Share & Learn Series, business logic problems are not directly associated with coding errors. Although coding issues may be part of the problem, business logic errors are most frequently a result of design flaws or incorrect logical assumptions when an app is first created.
Business logic problems can happen if a user takes an unanticipated action when using an application. This can be almost anything - from unexpectedly cancelling an order, applying a coupon code too many times or simply skipping an expected step and taking an action that the application does not know how to handle. Exploiting business logic flaws does not even require any training, just a malicious user with an inquisitive mind willing to think outside the box.
In this episode, we will learn:
Unlike most exploits, we can't point to specific strings of code that could cause this vulnerability. Instead, it comes down to users taking actions that have not been anticipated, and which programs don't know how to handle. As an example, let's say a banking application allows users to transfer money to other accounts. But instead of sending money, a malicious user tries to send a negative amount to another account. How will the banking application react? Will it crash? Will it deny the transfer? Or might it actually send money back to the user who initiated the transfer to balance that negative number?
E-commerce sites are particularly, though not uniquely, susceptible to business logic flaws because they are designed to be interacted with by a lot of users, and have many components. Users cancelling orders unexpectedly, trying to apply single coupons multiple times or even overloading their shopping carts can present applications with conditions that have not been anticipated. There is really no way to know how a program will react when confronted with an unknown situation. The best case scenario might be generating an error message, but there is no guarantee that an app won't take a worse action, such as providing merchandise for free.
Business logic problems can be extremely dangerous because they can be exploited by anyone, even someone with no programming or hacker training. It really only requires experimentation and time, clicking around and attempting to find flaws in the way an application is designed to respond. And once a malicious user discovers a flaw in the business logic of a site, you can bet they will exploit it as much as possible.
The biggest danger is normally financial, having a user purchase 20 big screen televisions without paying for them, or something like that. But business logic flaws can also cause other issues. For example, if the password function protecting a site does not know what to do if a user constantly hits cancel, it might let them bypass the login process all together.
There is really no way to anticipate how much damage a business logic problem could cause. Often the first indication of a problem comes long after users have exploited them.
Unfortunately, using common tools like vulnerability scanners won't help identify or fix business logic problems, since testing for business logic issues cannot be easily automated. The best way to avoid them is to implement good planning, error handling and testing for negative test cases while an application is being developed. This first requires a clearly defined set of business rules that includes all possible and desired actions that an application is designed to take.
Armed with a business rule plan, one of the best ways to prevent business logic flaws from creeping in is to create a flow chart showing all the possible ways that data and transactions should flow within an application. This includes modeling behavior for every instance where a user is able to make a choice or input data. Constantly check to ensure that the possible actions in the flow diagram match the functions in the business rule plan.
Finally, use threat modeling to help identify flaws in the business logic during the design, implementation and testing phases. As a failsafe, create an action that the program should take if it encounters any situation not specifically anticipated. This could be as simple as denying the action and alerting an administrator about the encountered problem.
For further reading, you can take a look at the OWASP pages on business logic problems. You can also put your newfound defensive knowledge to the test with the free demo of the Secure Code Warrior platform, which trains cybersecurity teams to become the ultimate cyber warriors. To learn more about defeating this vulnerability, and a rogues'gallery of other threats, visit the Secure Code Warrior blog.
Ready to seek and destroy business logic vulnerabilities right now? Head to the platform and test your skills: [Start Here]