Software applications have become significantly more complex over the past decade. This bodes well for the creation of new application-based business opportunities and additional customer touchpoints, however increased software complexity also opens the door for more malicious attacks and high-impact data leaks. Ever-nimble and determined threat actors are reinventing their approaches to align with current software development trends, exploiting newer vulnerabilities that have common characteristics across different applications, as well as ones that are specific to an application and business domain.
RELATED CONTENT: Top considerations for DevSecOps to reduce security risk
Software vulnerabilities with common characteristics across different applications (such as cross-site scripting and SQL injection) are fairly easy to identify through pattern-matching techniques. However, pinpointing vulnerabilities that are specific to an application and business domain is more challenging because there aren’t necessarily any common characteristics.. Business logic flaws refer to security weaknesses or bugs in the functional or design aspect of an application that typically go undetected by existing web application scanners. They allow attackers to misuse an application by circumventing its business rules, and are often disguised as syntactically valid web requests that carry out malicious intentions to violate the intended application logic.
How seemingly minor design errors can lead to a massive exploit
Consider the following business logic flaw example: In 2012, the blog pixus-ru published a combination of six expected design behaviors in Skype that led to an exploit. The design errors allowed a user to create an account by providing a valid email address. However at the time, Skype did not verify that the given email address existed and belonged to the current user (i.e. a step in account completion to validate email association). Another error allowed the binding of multiple accounts to the same email address.
With these design errors, attackers could create a new Skype account based on the email address of an existing user to then initiate a password reset. Then, because of the account’s binding described in the design error, the application would ask the attacker for the name of the Skype account to reset. Attackers could then change the initial user’s password and obtain full access to the targeted Skype account, due to the weakness of the recovery phase combined with an insufficient identity verification.
3 core classes of business logic flaws
Proactively identifying business logic flaws proves difficult because such flaws are usually fully intertwined with the business logic of web applications. As a result, it’s crucial that DevSecOps teams understand the different classes of logic flaws associated with authentication and authorization, including the registration phase, authentication and recovery/reset. The registration phase represents an application failing to properly manage credentials for a given identity, and/or not sufficiently verifying and ensuring that the given identity information “objectively” exists and pertains to the claimant. It also can involve registration failing to provide sufficient information for permit recovery or credential reset, and contains multiple paths with different security levels.
The authentication class of business logic flaws refers to when authentication mechanisms don’t support or improperly limit the number of attempts to get authenticated. Authentication mechanisms don’t guarantee the entity’s authenticity and non-repudiation, and like with the registration phase, support multiple paths with different security levels. Regarding the recovery/reset class, registration mechanisms suffer from weak credential recovery, and applications don’t sufficiently authenticate the current entity while recovering or resetting a credential.
Best practices for proactively preventing business logic flaws
To protect against the risks of business logic flaws, DevSecOps teams should establish a repeatable, blueprint-like guide for conducting routine checks against the various classes of logic flaws as part of their continuous integration and continuous delivery (CI/CD) process. For instance, for the registration phase, credentials uniqueness checks, identity verification checks, credential recovery/reset checks and path checks should be implemented. For authentication, interaction frequency limit checks, insufficient authentication and verification checks, weak path checks and session limitation checks are necessary. Lastly, weak recovery process and entity authentication checks should be leveraged for the recovery/reset class.
Equally essential in preventing business logic flaws is modeling a propagation graph to fully understand the authentication scheme associated with applications. Propagation graphs are directed graphs that model all information flow in one program. The nodes of a propagation graph represent methods and/or code blocks, and the edges represent explicit information flow between methods. A classification of nodes in a propagation graph into sources, sinks and sanitizers is called an information flow specification or simply a “specification.” With a propagation graph and a specification, DevSecOps teams can easily run a reachability algorithm to check if all paths from sources to sinks pass through a sanitizer.
Specification models should also extend beyond vulnerability discovery. To be truly effective, the specification should be able to extend itself to detect insider attacks and root-kits placed intentionally with malicious intent. In addition, all of the checks should be automated as regression test. In doing so — and by creating criteria blueprints based on the best practices described above and/or organization-specific needs — DevSecOps teams can insert security into their CI/CD pipeline for every release to ensure that the application architecture is adhering to the prescribed blueprint and no vulnerable conditions, business logic flaws or insider attacks exist within their application’s code base.
