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