What is a web application logic flaw?
A logic flaw is something that happens when the application (website, mobile app, webservice…) does not behave as expected.
It generally happens when some logic or workflow can be avoided or circumvented.
Imagine a simple website where you can buy t-shirts.
The usual workflow is the following:
- The consumer adds t-shirts to the basket.
- The consumer pays with their credit card.
- The consumer finalizes the order.
A malicious guy comes to the website and does the following:
- Adds 2 t-shirts to his basket.
- Pays with his credit card.
- Adds more t-shirts (10) to the basket.
- Finalizes the order and gets 12 t-shirt, for the price of 2.
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 cash counter’s conveyor.
But what if a malicious consumer hides an article in his caddy? The cashier will not see the article and the consumer will get it for free.
Each logic attack is almost unique, since it is an exploit of a function or feature that is specific to the web application.
Depending on the nature of the application, logic flaws can be very powerful and dangerous. When dealing with password recovery processes, or other sensitive transactions, damages become very serious.
On top of the potential damage they can cause, logic flaws are the hardest to detect when compared to usual technical flaws (XSS, sql injection, CSRF…)
How to detect a logic flaw?
Detecting logic flaws goes beyond what any automated tool can do. Automated tools are not too bad at detecting some technical vulnerabilities under certain circumstances, but not able to understand the expected (an hence unexpected) behavior of a given web application.
(For more details about why automated tools are not sufficient, please read this article: Why using web app security automated tools is not enough)
Detecting logical weaknesses starts with a full understanding of what is expected from the application. With this in mind, the security tester must have this big bunch of creativity that will help them building unexpected workflows and test them against the app.
Security testers must think “out of the box” (with the box being the functional scope of the application). For security people, pentesters or attackers, there’s just no box at all!
Why logic flaws?
Logic flaws usually come from a lack of rigorous design and a lack of thorough testing from a security standpoint.
A lax SDLC (software development life cycle) implies a poor control of design and also lax controls in the application itself.
It is also worth noting that logic flaws too often go through a Quality Assurance process without being caught, since QA testers usually focus on what the application is supposed to do (and not what it is not supposed to do).
How to avoid such vulnerabilities?
Unlike technical vulnerabilities, frameworks and libraries cannot provide a good protection against these flaws.
The only real solution is to perform sanity checks by validating business processes and design requirements at the start of the development lifecycle.
Then, implementing appropriate controls at every stage of each workflow will ensure that the business logic cannot be abused or circumvented.
Doing a pentest on web applications is a way to discover these logical weaknesses, in order to fix them.
As said earlier, lax processes and bad design create these flaws. Setting up logical controls and restrictions kills the problem.
Going back to our e-commerce example with the t-shirt website, a control must be put in place in order to ensure that articles cannot be added to the cart once the order has been paid.
In our physical supermarket example, asking the cashier to systematically look at the caddy can mitigate fraud.
Some examples of logic flaws
All below examples are real and have been encountered on the Internet.
Still in the e-commerce area, let’s suppose that your website’s basket adds a gift to a consumer when reaching a certain total amount. Technically, your developers chose to implement this “gift” by adding a normal article that is usually sold 8 EUR, and by also adding a “discount” item of -8 EUR to balance.
Now, the consumer removes the gift, but the website does not remove the discount item! This way, any consumer can get a 8 EUR discount, which is not the expected behavior.
To avoid this problem, the system must remove the discount item along with the gift article when that one is removed from the basket.
Last example in the e-commerce world, that can actually be valid in other scenarios:
The basket displays articles that the consumer selected, and uses hidden form fields to store items’ prices.
If a malicious user modifies the content of these hidden fields while submitting the basket to proceed with checkout, he can the modify the prices.
To get rid of this weakness, the website must not rely on hidden form fields (client-side information), but rely on price information stored on the server.
On a banking website, a user can perform fund transfers to any account.
There is no control on the amount that is specified by the user.
A malicious user decides to specify a negative amount for his transfer.
Instead of sending money to account B, the malicious user pulls money from that account.
A control on the amount is a way to prevent the issue.
Build your own example!
Take any scenario from a website, and be creative. Imagination is the only limit, until developers put in place appropriate controls.