Business logic vulnerabilities and some common scenarios of business logic flaws

Web applications have become the core mechanism for business processes over the Internet. As more and more businesses are migrating to the Internet model, it has led to various information security issues and vulnerabilities. SQL Injection, Cross Site Scripting, Remote Code Execution to name a few. However apart from the conventional vulnerabilities, there are many forms of business logic vulnerabilities commonly exploited by attackers. These vulnerabilities are routinely overlooked during QA because the process is intended to test what a piece of code is supposed to do and not what it can be made to do. The other problem(s) with business logic flaws is scanners can’t identify them, IDS can’t detect them, and Web application firewalls can’t defend them.

Thus, business logic vulnerabilities are ways of using the legitimate processing flow of an application in a way that results in a negative consequence to the organization. Automating business processes such as customer purchase orders, banking queries, wire transfers or online auctions, for example, requires entities to have access to extremely sensitive information.  Improper implementation of these can lead to the business logic flaws.

Some common scenarios of business logic flaws

  • For a Personal banking site, X’s (valid user) profile can be fetched with id=19023 and if this value changed to 19035 we get another user’s information. A scanner may go on and change the value from 19023 to ‘19023 to find SQL injection, but not to 19023 and would miss deducing that the application is vulnerable to authorization bypass.

  • An online movie booking service has a seat allocation process that requires three steps. In the last step, the application sends confirmation to the user. A user figures out a way to bypass step two and go directly to step three. While the application attempts to pass the seat allocation information in step three, the user can inject an upgraded seat assignment in premium class. The application does not detect the injection and assumes the user is following the proper steps and allocates a seat in premium class.
  • A banking application allows   users to fetch their transactions in XLS format. When such a request is made a temporary link is created for downloading the information through which statement is available. An attacker can analyze this mechanism and identify the hidden call. If proper authorization for the call is not implemented, then it leads to possible compromise. An attacker can analyze the file naming convention and start guessing for other users’ URLs and extract this information from the application. This flaw can prove very deadly since it leads to privacy and security concerns for the application owner.
  • We have a URL to download a document. Clearly, by guessing a user ID, an attacker can find other documents residing on the server.

Conclusion

Business logic flaws are pervasive and extremely diverse. It’s easy to see why even the best QA processes overlook these issues because they typically don’t check for what the system can be manipulated to do. And, vulnerability scanners, intrusion detection systems, and Web application firewalls would have an equally hard time because the attacks look more or less like “normal” traffic. Data value requires knowledge of context and does not know what the website is supposed to do, or the path through the logic, so it can’t tell if it did something wrong. To find these business logic issues, the pairing of experienced security experts with automated scanning is a best practice for achieving complete website vulnerability coverage.

Authored by Manish Periwal

Rate this article: 
Average: 2.4 (7 votes)
Article category: