What are Business Logic Vulnerabilities?

In today’s world, where hackers are becoming more sophisticated with each passing day, penetration testers must not rely just on automated scanners to identify application flaws. It is a requirement of the time that testers grasp the deep concepts on which the application is based. This is because it is by this method that we can insulate our apps against business logic flaws.

How do these arise?

Business Logic Vulnerabilities arise when developers do not truly understand the application’s users and just try to build the application’s functionality. As a result, they leave some critical parts behind that would later become the reason for the application’s exploitation. Business logic vulnerabilities also imply that the logic applied by the developers has a logic flaw, i.e. the application will modify its behavior if a normal user or threat actor disrupts the typical way of performing that function.

Impact of business logic vulnerabilities?

The impact of business logic vulnerabilities is entirely dependent on where they were discovered. These can have a minor impact, such as information disclosure, or they can have a major impact, such as account takeover. We’ll look at various cases in this article that include logic flaws relating to user logins and payment methods.

Let us now look at some examples that can clear basic concepts related to business logic vulnerabilities.

The business logic flaw in login/ Password Reset

The following scenarios demonstrate weaknesses in the application’s login sequence. These examples will show how developers make assumptions about the system’s usual behavior, which can lead to business logic vulnerabilities.

Scenario 1:

The flaw in password reset functionality

Password reset functionalities are made secure by sending a specific link to the required user. The user clicks that link and a form opens to set the new password. A good use-case in this scenario is to check whether we can use this functionality to set the password for some other user. A successful attack scenario can have the following steps:

Attacker sends a normal request for password reset functionality
Attacker receives password reset link in email
When a user clicks the link
- In the request, a unique username of the attacker is sent with the request, and new passwords
If the attacker changes its username with any valid username, it changes the password for that specific username

If we do not take care of the user whose password is being reset and allow the user to take control of it, attackers can simply take over the accounts of genuine users using this way of resetting the user password.

Scenario 2:

Bypassing 2FA Authentication Mechanism

Almost every application today has 2FA (two-factor authentication) to protect users against account takeover attacks. 2FA adds an additional layer of protection to the application, protecting it from hackers. Developers that do not grasp the entire flow of 2FA implementation may leave a logical fault in the code.

Below is an example of a simple 2FA bypass.

Assume we have an application that takes the user’s username and password and checks to see if they are correct. After this successful operation, the user is prompted to enter two-factor authentication (2FA). When a legitimate user provides the right 2FA, the application redirects the user to the application’s dashboard.

We may be able to find an opportunity to check for a logical problem in this type of application here. An attacker may attempt to access the page that follows the 2FA authentication request directly. If there is no backend check to see if the user has been verified using both password and 2FA, the attacker can gain access to the user’s account if the attacker already knows the password.

Scenario 3:

Letting User Control the User-Role

This specific scenario is about the applications where a user opts for the role he is going to use in the application. The basic information regarding this scenario can be assumed as follows:

The application allows the logged-in user to select a role
- For simplicity, let us assume the role
  - Task Creator
  - Task Approver
When the user logs into the application, the user is given the option to choose from the available roles so that the user can perform the tasks accordingly
The use-case here to check for a possible vulnerability is:
- Suppose there is an admin panel as well and that is accessible through a URL i.e. https://example.com/admin
- Suppose we found the URL through fuzzing
- Now if we try to access this URL, the application stops us saying that we are not the admin
- In this case, what we can do is we can try to change our role to “administrator”, “admin” etc
  - To accomplish this, we can change the request by intercepting it in burp. We can change the role from “Role Creator” to “admin” or “administrator.
- If this is successful, the user will get the role of admin or administrator.
- Now as the user has been logged in as an admin and we know the URL for the admin page so we can now try to get access to the admin panel and get unauthorized access to it.

Business Logic Flaws in purchasing flow of applications

We have seen a few examples of business logic flaws in the logic of user authentication. Let us see a few basic causes of business logic flaws in purchasing flow of the applications. These scenarios are basic, but the purpose of describing them is to give awareness against these basic flaws and make our applications secure right from the start.

Scenario 4:

Letting users control the price

A very basic scenario is that developers get the product price from the database to show it to users, and when the user adds the product to the cart, the price added against the product also goes in the same request, which the user can intercept with a simple tool like burpsuite. Users must now be allowed to adjust prices. The sensitive work, such as processing prices and vouchers, should be handled automatically in the application’s backend. In this situation, we can modify the value after reading the traffic in burp, and if there are no back-end checks, we can purchase the items at our own pricing. The sample request can be seen below:

Scenario 5:

No input validation on quantity

Another basic scenario in purchasing flow of an application is that users are not allowed to edit the product prices as these get handled by the application at the backend. But, we cannot restrict users to not changing the quantity. And in this scenario, the quantity should be checked properly so that the user cannot enter a quantity less than 0 or any value that affects the total value in a negative way. The scenario is as follows:

The user is allowed to change the quantity of the product
The user adds a product (product A) worth $500 making the total amount in the cart $500.
If the user tries to enter a negative quantity for the same product, it will give no benefit as nothing is getting purchased.
But, what we can do is we can try to add some other product (let’s call that product B) that has lesser value e.g. $50
Let us say we added the quantity for product B 5. It will add $250 to the cart making the total value of our cart $750.
But if we try to add a negative quantity for product B, and there is no backend validation then this amount will be subtracted from our cart as well. Suppose we added a -5 quantity for product B, then the total value of our cart will become $250 ($500 – $250).

The sample request can be seen below.

Scenario 6:

Integer Overflow

Another scenario in purchasing flaw related to quantity is no handling of integer overflow in the application. This scenario is popular in the applications that handle purchases in big quantities. The idea here is to check the boundaries of variables that handle the amount of our cart. Suppose an application uses an integer for handling the amount, then we can try to make the value of that integer so large that it overflows and resets its value back to 0 while the quantity is still a large number.

The scenario is as follows:

The user adds an item to the cart.
Now user uses the same request to send a large number of requests using the burp intruder.
If the application is using an integer to handle the total amount, the largest value it can contain is 2,147,483,647.
If there is no quantity barrier and the user is allowed to get as much quantity as he can then we can try to make amount a number that is greater than this value making our integer overflowed. If there are no backend checks on the integer value, then integer value will reset itself to 0.
The quantity in cart grows incrementally but the amount grows towards 0.

This way we can alter the behavior of the application from a normal one.

Scenario 7:

Assuming only valid sequence in purchasing order

Every step in the purchasing sequence matters a lot e.g. letting user select the product, identifying correct product with correct price and all error handeling. Each step takes user towards the next step making the system efficient. When so many steps combine in a specific sequence to complete a process, it is the responsibility of the tester to test the process for abnomal behaviours as well.

Our next scenario is about the above described situation. A white-hat once reported that he was able to purchase items even without spending a single cent. There was nothing wrong in the sequence except that the system was not able to identify if a singe step was removed from the process.

The process was as follows:

System allows the user to select the product and quantity
User goes to checkout
System checks whether the user has the balance for the purchase or not
System verifies the balance and asks the user to send a confirmation request so that the order can be placed finally

The above scenario works perfectly. But the critical thinking of hacker made him to check what happens if the system does not verify the balance?

And yes, the hacker only took out a step of verification from the process and he was able to completely exploit the system.

The hacker did everything as expected. When he added items in the cart, instead of going to checkout, he directly sent the confirmation request and the purchase got successful. That is how a very small modification in the process can have a very large impact on businessess.

Scenario 8:

Infinite money logic flaw

Coupens play an important role in the applications. There can be many logical flaws in the implementation of coupons while purchaning. A very interesting scenario is “Infinite Money Logic Flaw”. The details are as follows:

A user gets coupen code to buy an item e.g. 20% off
The user uses that code to purchase a gift voucher for someone i.e.
- Purchased a gift of worth $10 for $8 after 20% discount
Te user now uses that gift code on his own profile and gets 10$ as a gift in his own account
Ammm why? So it means, the user spent $8 but got $10.
If user repeats this activity then unlimited amount can be retrieved fulfilling infinite money logic flaw

Similarly in case of coupen codes, we must check whether user can enter a voucher code multiple times to get unusual discount. For example,

Checking coupons:

First, check if we can use one voucher multiple times
The check if we can use multiple vouchers
- If yes then check if we can apply coupons multiple times in an alternate way
  - Apply 1 coupon
  - Apple second coupon
  - Then again apply the first coupon
  - If the application accepts 3rd coupon in this sequence then we can use this flow to minimize the cost

These were some of the basic logical checks that the developers of an application must perform before making the application live in the production mode to avoid any harm to the application assets.

Business logic vulnerabilities