Logic Bugs are unintended flaws in how applications process user input and interactions. Logic Bugs change the ways how applications behave. While normal usage can exploit logic bugs in an application, the parameter logic bugs required tools for exploitation. The goals is to find unintended behavior which we can take advantage of.
What are business logic vulnerabilities?
Finding logic vulnerabilities or flaws in design and implementations can lead to unintended behavior and is exactly what we want. We also call them application logic vulnerabilities or logic flaws. They are rules within an application defining how it should behave in real-word scenarios, think of payments, orders, permissions etc. Finding flaws we circumvent these rules.
Causes of Logic Bugs
Business logic vulnerabilities occur because of flawed assumptions about how users will interact with the applications caused mainly by bad coding. Also not properly testing applications will make developers miss logic bugs. We see logic bugs in overly complicated systems where even the own developers have lost track of all the flows and functions.
Logic Bugs Types
We can split Logic Bugs into 2 types:
- Parameter manipulation
- Flow bypasses
| Type | Description |
|---|---|
| Parameter Manipulation | Application's logic cannot properly handle a specific type of parameters |
Validation Logic Disparity |
Where validation logic varies between front-end and back-end. |
Unexpected Input |
Where bugs are caused by different types of input the application cannot handle. |
Null Safety |
Where bugs are caused by not properly handling null parameters. |
Or the Forwards flows
| Type | Description |
|---|---|
| Flow Bypass | An application's flow can be broken due to certain flaws in its design |
Repeating One-off Actions |
Where we are able to repeatedly use actions that should only be carried once. |
Out of Order Steps |
Where we break a multi-step process by doing steps out of order. |
Unexpected Behavior |
Covers all other flow logic bugs, usually caused by a user behavior the application isn't designed to handle. |
What is the impact of Logic Bugs
If an attacker is able to manipulate application in such a way it can lead to high severity attacks. It can be used to escalate privileges, bypass authentication or gain access to sensitive information.
Excessive trust in client-side controls
Assuming users will only interact with the web application client side is dangerous because attackers can easily tamper with data with tools like Burp
Failing to handle unconventional input
User input should be restricted to maintain safe application logic. Many applications have numeric limits in place to manage inventory, apply budgetary restrictions, trigger phases of the supply chain.
Webshop: Ordering products users specify a quantity but max amount based on stock is in place to avoid users ordering more than in stock.
Developers must anticipate on all possible scenarios to handle this logic. If they forget or do not properly anticipate on scenarios exploitation might be possible. For example negative integer should not be possible.
$transferAmount = $_POST['amount'];
$currentBalance = $user->getBalance();
if ($transferAmount <= $currentBalance) {
// Complete the transfer
} else {
// Block the transfer: insufficient funds
}If the attacker sent -$1000 to the victim's account, this might result in them receiving $1000 from the victim instead. More example
- Exceptionally high or exceptionally low values
- Abnormally long strings
- Unexpected data types ( age = abc)
Inconsistent handling of exceptional input in email registration
testtesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttesttestte@dontwannacry.com.exploit-0a8a000c044f4c4880a4115a013600b5.exploit-server.netAs the server is truncating at a certain value you can use this to send in the right amount of chars so the email adress will end at the m of .com effectively stripping of the rest and ending up with a valid email.
User behavior
Developers can assume users to be trustworthy after passing initial checks but this can result in security measures not being properly applied after these checks making it possible for example to change email address into sensitive email addresses. It becomes more interesting when we can remove or add parameters.
Removing parameter values may allow an attacker to access code paths that are supposed to be out of reach.
When checking for logic flaws:
- Only remove one parameter at a time
- Try deleting names as wel ass values of a parameter
- Tamper with parameters in all stages of multi process stages.
We can remove a current password parameter and changes someone elses password
# Original request
username=wiener¤t-password=peter&new-password-1=peter&new-password-2=peter
# Remove current password parameter
&username=administrator&new-password-1=peter&new-password-2=peter