Business logic flaws
Security issues are better known these days than they used to be, and it is not uncommon to find software developers aware of some application security concepts such as SQL Injection or XSS. However, the same does not occur with concepts such as Business Logic Flaws (also known as Security Design flaws), which represent about 50% of security problems.
It is not easy to understand why such a significant proportion of security issues go unnoticed but there are many reasons for this.
First of all, they are not easy to describe, because in many cases they are based on a combination of different things. Probably the best way to define business logic flaws is to describe what they are not about. Security design flaws or business logic flaws are security issues that cannot be detected by tools such as ASTs. In other words, they are business specific and do not follow a specific pattern of risk and therefore they have to be detected by auditing the applications manually.
A slightly different description could be that design flaws are not located only in a specific file and line of your code. Instead, these kinds of issues are more related to the general security architecture of the application and the problem is spread over many areas of the source code. Therefore the detection of business logic flaws cannot be automated.
Tests of business logic flaws are similar to those used by functional testers focusing on logical or finite state testing. These types of tests require security professionals to think a bit differently, develop abuse and misuse cases and use many of the testing techniques embraced by functional testers. Automation of business logic abuse cases is not possible and remains a manual art relying on the skills of the tester and their knowledge of the complete business process and its rules.
Secondly, the impossibility of detecting these issues makes them unattractive to most of the security industry, leading to a lack of awareness of these risks as they are rarely mentioned by the big companies. Therefore, an application security strategy that is only based on Application Security Testing tools (AST), will only be detecting 50% of the problem as these tools are unable to detect any issue related to security design flaws or business logic flaws.
The issues are similar when using protection solutions such as Web Application Firewalls (WAF). We should take into account that many of them are only designed or configured to protect against some specific common attack patterns, but business logic flaws are not included in those patterns. So, it is very common to have production environments protected by WAFs that are vulnerable to 50% of risks.
An interesting additional post on this topic that is worth reading is Top 10 Security Design Flaws. Created recently by the IEEE Computer Society, it gives the reader an insight into the full scale of the problem.
The pragmatic approach of Hdiv is to try to protect the application against business logic flaws instead of trying to detect them. This can by done by solving the root cause of all business logic flaws as these kinds of vulnerabilities all have something in common - they are based on malicious crafting of URLs, parameters... on the client side. Hdiv limits end user interaction, avoiding the manipulation of data, therefore protecting from such risks.
Basically, Hdiv enforces the contract offered by the server side avoiding any kind of unexpected behavior.
With regard to OWASP Top Ten Risks, there are three which are directly related to business logic flaws:
A4 Insecure Direct Object Reference¶
Hdiv’s web information flow control system controls all the data generated at the server side and ensures its integrity when it comes back. In addition, an optional feature makes it possible to ensure the confidentiality of data generated at the server side, avoiding the exposure of critical data (such as credit cards, etc.).
A7 Missing function level access control¶
Thanks to the information flow control system implemented by Hdiv, all the resources (links and forms) displayed by the application are controlled and in this way the original contract offered by the server cannot be broken.
A10 Unvalidated redirects and forwards¶
Hdiv controls all the data sent by the server and does not allow redirection to malicious websites.