Updated: 16 Feb. 2021
Business logic flaws remain a type of little-known vulnerability in IT-Security. They are not errors in the logical reasoning, but flaws related to the working of a web application. They are different from technical vulnerabilities, which directly relate to code, implementation or configuration errors.
We regularly find logic flaws during penetration tests, on all types of applications. We find them most frequently on e-commerce sites and SaaS software.
What are logic vulnerabilities? How to detect them? How to avoid them?
After understanding how these vulnerabilities work, we name five main categories of logic vulnerabilities and give you specific questions to help identify them during tests that can be conducted internally or during a security audit. Finally, we’ll give examples we’ve encountered during penetration tests.
What is a Logic Flaw on Web Applications?
A logic flaw happens when an application (website, mobile app, webservice…) does not behave as expected.
It occurs when some logic steps or a workflow can be avoided, circumvented or manipulated by an attacker. The attacker diverts a workflow in its own interest, it isn’t a technical mistake in itself.
Business logic flaws can often be exploited without specific technical tools, sometimes simply by manipulating the url or the htlm code of the page. Generally, using a proxy to intercept and play again requests helps to find and exploit these flaws.
Imagine a website where you can buy t-shirts.
The usual workflow of a client is the following:
- Adds t-shirts to the basket.
- Pays with their credit card.
- Finalises the order.
A malicious person comes to the website and would for example exploit a logic flaw as follows:
- Adds 2 t-shirts to the basket.
- Pays with their credit card.
- Adds more t-shirts (10) to the basket.
- Finalise the order and gets 12 t-shirts, for the price of 2.
Logic flaws also exist in real life. We can compare this e-commerce example to what can happen in a physical supermarket. The normal ‘workflow’ of a supermarket supposes that consumers put all articles they want to purchase in their basket and then on the conveyor belt.
But what if a malicious consumer hides an article in their shopping cart when passing the checkout? The cashier will not see the article and the consumer will not pay for it.
Each logic attack is almost unique, since it exploits a function or feature that is specific to the application.
Depending on the nature of the application, logic vulnerabilities can be very powerful and dangerous, as they are related to the functioning itself of the solution. When dealing with password recovery processes or other sensitive transactions, it causes some very serious damages.
Business logic flaws are harder to detect than technical flaws (XSS, sql injection, CSRF…). Technical vulnerabilities are still too frequent, you can by the way read our article about the most common attacks against web applications.
But logic vulnerabilities remain usually less studied, less tested and their impact is often underestimated.
How to Detect a Logic Flaw in an Application?
Finding logic flaws goes beyond what any automated tool can do. A penetration test enables to discover them. It is necessary to study and to understand the expected (and hence unexpected) behaviour of a website or a mobile application and to think ‘attack’: which gains could obtain attackers in this situation?
Vulnerabilities scanners are not bad at detecting technical flaws when conditions are good. They are testing technical flaws related to code or configuration errors. But they are not able to understand a situation and to think about how to circumvent or divert a control.
A scanner would for example not know that accessing another user’s invoices by changing the url is a logic flaw.
Detecting logical weaknesses of an application requires identifying the expected working of this application, to understand in depth the business logic and the benefit an attacker could get. With this information in mind, pentesters use their creativity to build unpredicted scenarios and to test them against the app. Only a human being can find an alternative solution in a user journey and judge whether bypassing this step is relevant or not.
Uncovering logic flaws involves
- having a full understanding of what the application is supposed to do: business rules, processes…
- dividing and modelling the workflow,
- identifying where controls are carried out, and where they are not,
- analysing the controls carried out, the parameters sent, the responses returned…
Why are there Logic Flaws?
Logic flaws exist when an application does not take the appropriate measures to handle an unexpected behaviour. The attacker bypasses a normal workflow and the application does not have controls in place to prevent it.
We can list some main ‘categories’ of business logic flaws:
- flaws related to a lack of robustness in a workflow, which can be circumvented,
- flaws related to a lack of control over data, which influence actions being carried out,
- flaws related to an unexpected reaction of the application,
- flaws related to temporal attacks,
- flaws related to functionalities, which only become problematic when combined.
Logic flaws usually come from a lack of rigour in the design and a lack of thorough security testing of the solution’s business processes.
First of all, the development and QA teams are not very aware of this type of vulnerability. We can note that logic flaws often pass through quality controls without being detected. QA testers generally focus on what the application is supposed to do (and not what it is not supposed to do).
Then, logic flaws remain present as well because it is difficult for someone in the company to have a fresh eye on processes they work on and to put themselves in the mindset of an attacker looking to break the rules of business logic.
How to Prevent Logic Flaws on Applications?
Unlike technical vulnerabilities, frameworks and libraries cannot provide a good protection against these flaws.
The only real solution is to perform checks by validating business processes and technical-functional requirements at several stages of the development cycle. It is crucial to not only integrate security tests at the end of the project, as design errors at the early stages of development can be difficult to catch up on later when they are embedded in the core of the application.
For these tests, QA/security teams need to know in detail the working of each part of the application and the business logic. A complete understanding of the technologies used is also necessary, in order to control the implementations and associations of the different technologies.
A reflex to take is also to document business processes and rules in addition to the technical documentation.
Then, implementing appropriate controls at every stage of each workflow will ensure that the business logic cannot be abused or circumvented. You can rely on quality management methods, asking the questions for each stage in particular, like:
- Who, from whom, to whom, with whom, for whom?
- What, towards what, with what…
- Where, to where, from where…
- When, how often, for how long
- How, by what means…
- How much, what quantities…
- Why, what cause, what purpose?
Finally, performing a penetration test on the website or the applications is a way to discover these logical weaknesses, by pentesters who are used to search these vulnerabilities, so that you can fix them.
Going back to our example, the t-shirt website. A control must be put in place in order to ensure that articles cannot be added to the current order, once it has been paid for.
In the physical supermarket example, the equivalent is to ask the cashier to systematically check the contents of the shopping cart, in order to reduce fraud.
Some Examples of Logic Flaws
Example A: Logic Flaw Linked to a Temporal Attack
During a penetration test on an event management site, there was a ticket booking functionality. When a customer started a reservation by adding tickets to their shopping cart, their tickets were blocked for other customers for a given number of minutes, to let the user have time to finalise their order.
During the attack, we created a script that reserved all the tickets. By running this script, we blocked the entire site. This was a denial of service (DoS), because real customers could no longer use the website to buy their cards. For the website, this leads to a loss of income (because users switch to competing websites), a loss of trust, a deterioration of their brand image….
To prevent this type of vulnerability linked to temporal attacks, several solutions are possible and can be combined depending on the situation: setting up a captcha at the beginning of the booking process, checking identity when creating the account (validating the telephone number for example), checking that a bank card is associated with only one account, etc.
Example B: Logic Flaw Linked to Bypassing a Workflow
During a pentest on an e-commerce website, users could finalise their order by choosing to pick it up at the shop and to pay on the spot. The staff at the shop would receive the payment and check the validity of the payment in cash or cheque.
However, when we had validated the order, we saw in the requests sent that the invoice was already generated. We were able to retrieve the access url to the invoice using a tool and print it before going to the shop. Thanks to this invoice, when we went to the shop, we were able to pick our order without having to pay it.
To resolve this, a step has been added to the workflow so that the invoice is only generated once the payment has been received.
Example C: Logic Flaw Linked to Bypassing a Workflow
One website had a subscription system for users to access its content. At the time of registration, each account received one free content download.
During the penetration test, we registered and then unsubscribed from the service. We then re-registered, and during this second registration with the same account we were entitled to a new content download.
A malicious attacker could have taken advantage of this vulnerability to download a large amount of content.
This vulnerability was possible because this behavioural scenario was not taken into account during development.
Example D:
Build your own example!
Take the user scenario on your solution, and be creative. Imagination is the only limit, until appropriate controls are put in place.