> For the complete documentation index, see [llms.txt](https://notes.dollarboysushil.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://notes.dollarboysushil.com/web-application-pentest/business-logic-vulnerability.md).

# Business Logic Vulnerability

## Business Logic Vulnerabilities - Overview

### 1. What "business logic" actually means

* Business logic = the set of rules that govern how an app is *supposed* to behave (not literally "business" - also called "application logic" or just "logic flaws")
* A logic vulnerability = the app does something unintended when you interact with it in a way the developers didn't anticipate
* Key trait: **no broken syntax, no injection, nothing "technically" wrong** - the app works exactly as coded, it's just coded to allow the wrong thing

### 2. Why these are different from every other vuln class

* Not caught by normal use - only shows up when you deliberately deviate from the intended flow
* Automated scanners basically can't find these - there's no bad character or payload signature to detect, just an assumption that doesn't hold
* Needs actual domain understanding (what would benefit an attacker in *this specific* app) rather than a generic payload list
* Makes them a strong area for manual testers and bug bounty hunters specifically

### 3. Root cause, every time

* Developers assumed users would behave a certain way, and didn't code for what happens if they don't
* Common version of this assumption: "users only interact through the browser we gave them" → validation lives client-side only → trivially bypassed with a proxy
* Bigger/more complex systems = more of these gaps, because no single developer understands every workflow end to end

### 4. Impact - depends entirely on what the flaw touches

* Flaw in **auth logic** → account takeover, privilege escalation, full auth bypass
* Flaw in **financial/transaction logic** → direct monetary loss, fraud
* Even a flaw with no direct attacker benefit can still be a way to damage/disrupt the business
* Rule of thumb: fix weird behavior even if you can't figure out how to exploit it yet - someone else might

### 5. Category 1 - Excessive trust in client-side controls

* Root assumption: "the only way to reach my server is through my own frontend, which already validates this"
* Reality: Burp Proxy/Repeater sits between browser and server - any client-side check is optional for an attacker
* What to look for:
  * [ ] Price, quantity, discount, or role values sent from client and just trusted server-side
  * [ ] Hidden form fields or disabled UI elements that still get processed if resubmitted with different values
  * [ ] Anything validated only via JS, with no matching server-side check

### 6. Category 2 - Failing to handle unconventional input

* App restricts input on the frontend, but the backend never actually enforces the same limits
* Classic example: transfer amount check that only compares `amount <= balance` - sending a **negative amount** passes that check and reverses the direction of the transfer
* What to test:
  * [ ] Extremely large numbers
  * [ ] Negative numbers where only positive makes business sense
  * [ ] Zero, where zero shouldn't be valid
  * [ ] Wrong data type entirely (string into a numeric field, etc.)
  * [ ] Very long strings in text fields
* Questions to ask as you test:
  * What limits exist on this input?
  * What happens right at the edge of that limit?
  * Is my input being transformed/normalized before use - could that transformation itself be abused?
* If one form on the site mishandles this, check every other form doing something similar - same dev team, same blind spot, usually repeated

### 7. Category 3 - Flawed assumptions about user behavior

#### 3a. "Once trusted, always trusted"

* App enforces strict checks the first time (e.g. at signup or first purchase), then relaxes enforcement afterward assuming the user/data is still fine
* Test: does re-verification happen on later actions, or only once at the start?

#### 3b. "Users will always fill in mandatory fields"

* Browsers block empty-field submission, but a proxy doesn't care
* Multiple functions can share one server-side script - which parameter is present/absent may decide which code path runs
* How to test:
  * [ ] Remove one parameter at a time (not all at once - you need to isolate which one matters)
  * [ ] Try both: empty value, and the parameter name deleted entirely (server may treat these differently)
  * [ ] Check cookies too, not just URL/POST params
  * [ ] Follow the whole multi-step flow through - a param removed in step 1 can affect step 3

#### 3c. "Users will follow the steps in order"

* Multi-step workflows (checkout, 2FA, password reset) assume the user completes step 1 → 2 → 3 in sequence
* Classic case: login page → 2FA verification page. If the server doesn't actually check that 2FA passed before granting a logged-in session, you can skip straight past it
* How to test:
  * [ ] Jump straight to a later step's URL without completing earlier ones
  * [ ] Replay an earlier step after finishing later ones
  * [ ] Hit the same step twice
  * [ ] Watch for errors caused by skipped steps - null/uninitialized state often leaks useful debug info in the response

### 8. Category 4 - Domain-specific flaws

* Some flaws only make sense once you understand what the app/business is actually for
* Classic example: 10% discount on orders over $1000, with no check that the order total *stays* over $1000 after the discount is applied → add items to cross the threshold, get the discount, then remove the items, keep the discount
* What to look for:
  * Anywhere a price/value is adjusted based on conditions the user can manipulate (cart contents, order history, loyalty tier, referral counts)
  * Whether that adjustment is re-validated at the point of completion, or only calculated once and trusted after
* Needs domain knowledge - what's valuable to abuse on a social platform (followers, likes) looks nothing like what's valuable to abuse on an e-commerce site (discounts, stock)

### 9. Category 5 - Encryption oracle

* Happens when the app lets you submit arbitrary data to be encrypted, and hands you back the ciphertext
* Dangerous if that same algorithm/key is used elsewhere in the app for something sensitive (e.g. session tokens, access tokens)
* You can use the "oracle" feature to forge valid encrypted input for the other, sensitive feature
* Worse if there's also a decryption oracle somewhere - lets you learn the expected structure of legitimate ciphertext, making forgery easier
* Severity scales with what else relies on that same encryption

### 10. Category 6 - Email address parser discrepancies

* Different parts of the app (signup form validator vs. backend domain-extraction logic) can parse the *same* email address differently
* Email format is more complex than it looks, even for spec-compliant addresses
* Attacker crafts an address that passes the initial "looks valid" check but gets interpreted as belonging to a different (restricted/trusted) domain by the backend logic
* Impact: bypassing domain-restricted signup, sneaking into admin-only or org-only areas meant for a specific email domain

### 11. Testing checklist - run through this on any workflow

* [ ] Can any client-side-validated value (price, quantity, role, discount) be changed via proxy before it reaches the server?
* [ ] What happens with negative numbers, zero, huge numbers, wrong types?
* [ ] Is trust/verification re-checked on every sensitive action, or only once early in the flow?
* [ ] What happens if you delete a parameter instead of leaving it empty?
* [ ] Can you skip a step, repeat a step, or go backward in a multi-step process?
* [ ] Are discounts/adjustments re-validated at final submission, or just calculated once and trusted?
* [ ] Does anything encrypt user-controlled input and hand back the result - and is that same mechanism used anywhere sensitive?
* [ ] Are email addresses validated the same way everywhere they're checked, or could different components disagree on what domain an address belongs to?

### 12. Preventing these in your own apps (dev side, worth knowing either way)

* Document assumptions explicitly - what does this code expect to always be true?
* Validate everything server-side, regardless of what the client already checked
* Re-verify state at each sensitive step instead of trusting a decision made earlier in the flow
* Write workflows clearly enough that a flaw would be obvious just from reading the code
* When a weird one-off bug turns up, ask why it existed and how it slipped through - that usually points at a process gap, not just a single mistake