Business Logic

Business Logic is an attack that consists of using an application legitimately that results in negative outcomes for the application/company. (ie. there is some flaw in a legitimate process where going through the process results in something negative)

Attack Vector

This attack is quite dependent on the website or application being used; the attack itself can vary site by site. In order to understand the vulnerabilities that exist within a business, an attacker must be familiar with the business/website and have gone through the application's processes and user flows to examine/be exposed to any potential logical flaws.

Impact

The impact of a business logic attack varies depending on the business, the logical flaw, and what it actually exposes and allows the user to do that dictates the type of negative outcomes that can arise.

For example, a business logic attack that exposes a flaw allowing people to buy discounted goods, get reimbursed for more than is "allowed", or skipping a checkout payment.

Attack Examples

Example 1

Let's say there's a logical flaw at an online grocery store:

  • The store allows discounts when purchasing 10 items or more

  • Let's say we add 10 items to the cart and thus, all items are then discounted 15%

  • Then let's say, we end up removing 5 items from the cart

  • A logical flaw could exist here in that the remaining 5 items are still discounted 15% even though there are no longer 10 items in the cart

  • We now see the flaw in this legitimate process -- we get a 15% discount!

Example 2

Let's say there's a logical flaw in a money-transfer app:

  • We want to transfer $10 to a "friend" through an app

  • Let's say we enter a negative amount instead, for example, -$10

  • And let's say this app always checks to see if the amount we want to transfer is less than the total amount we have in our account

  • If the app only checks to see whether or not the transfer amount is less than the total amount in order to complete the transfer, else to not complete the transfer, we will end up in the "complete transfer" section

  • Here, we have followed a legitimate user process flow, but this is a negative outcome for the app

  • Perhaps, there are no other checks for the user-supplied input, and instead of transferring $10 to the "friend", we end up receiving $10 instead from the person we have sent this request to

  • This flaw is caused by assuming that users will only do what is expected of them, but that's not always the case!

Defenses

Some defences include proper sanitization or checking of user-supplied input, and testing different/unexpected processes and flows. Vulnerabilities can be overlooked by making assumptions about the behaviour or users or how they will use the application that is being built, so we should be cautious of our assumptions about users. And there should also be good documentation on the workflows and data flows.

Criteria for Demonstration

To demonstrate a business logic attack, (1) provide the sequence you have to go through to expose the vulnerability, and (2) what kind of unintended or negative outcome you end up with.****

Other resources

eli32