Business Logic Vulnerabilities

What are Business Logic Vulnerabilities

Business logic flaws arise when an application’s intended workflow can be abused in unintended ways — not through injection or standard attack patterns, but by manipulating the app’s own rules. They require understanding the application’s purpose and thinking about what it shouldn’t allow.

No automated scanner reliably catches these. They require manual testing and creative thinking.

---

Discovery Methodology

Step 1 — Map every function

In Burp Target → Site map, spider the app. Note every distinct function:

• Cart / purchase flow
• Account management (email, password, role changes)
• Discount / voucher systems
• Transfer / balance actions
• Approval / multi-step workflows
• Admin functions accessible via direct URL

Step 2 — Identify assumptions the app makes

For each function, ask:

• What does the app assume about the input? (amount > 0? single use? sequential steps?)
• What happens if you violate each assumption?
• Can you access later steps directly without completing earlier ones?
• Can you repeat a step that should only run once?

Step 3 — Test each assumption

Use Burp Repeater to modify one parameter at a time. Watch for unexpected 200 OK responses where you expected an error.

---

Pattern 1: Excessive Trust in Client-Side Controls

The app validates input in JavaScript but trusts whatever reaches the server. Hidden fields, disabled inputs, and client-side price calculations are all modifiable.

Hidden price field

Intercept a cart submission in Burp Proxy:

POST /cart/checkout HTTP/1.1

item=productA&quantity=1&price=99.00

Modify price:

price=0.01

If the server uses the submitted price instead of looking it up → purchase at any price.

Negative quantity

quantity=-1

If the app subtracts the item total → negative price credits your account or reduces total below zero.

---

Pattern 2: Flawed Workflow — Skip Steps

Multi-step checkout, multi-step verification, or multi-step admin approval flows often enforce sequence only in the UI. Test accessing a later endpoint directly:

# Normal flow: /cart → /checkout → /payment → /confirm
# Try accessing /confirm directly:
curl -b "session=SESSION" https://TARGET/confirm?orderId=123

If the confirmation succeeds without payment → order placed without paying.

In Burp Repeater: send requests to later-stage endpoints directly, bypassing earlier ones.

---

Pattern 3: Repeating Actions That Should Run Once

Actions that should be one-time: apply a gift card, use a discount code, claim a free item, cast a vote.

Test:

1. Perform the action once (success).
2. Send the exact same request again immediately.
3. If it succeeds again → no server-side uniqueness check.

Use Burp Repeater to resend. Also test resending after a page reload or from a different session.

---

Pattern 4: Discount / Coupon Stacking

If multiple discounts can be applied, test:

• Apply the same code twice.
• Apply a percentage discount + free shipping code simultaneously.
• Apply a code to a sale item (double discount).
• Apply a negative-value coupon to an already-free item (negative total).

POST /cart/apply-coupon HTTP/1.1

coupon=SAVE20

Send this request multiple times in Repeater. Check if the 20% discount is applied multiple times.

---

Pattern 5: Exceeding Quantity Limits

If there’s a per-user limit (max 1 of a limited item, max withdrawal):

quantity=999
quantity=1000000

Or split across multiple requests: add 1 ten times if each request passes the single-item check.

---

Pattern 6: Integer Overflow / Underflow

Large values may wrap around or cause unexpected behaviour:

amount=9999999999999999
quantity=2147483648
price=-1

If the server stores as a 32-bit int, 2147483648 overflows to negative — resulting in a negative price or balance.

---

Pattern 7: Inconsistent State in Multi-Step Flows

If step 1 grants a token/role that step 2 validates — and you can start a second flow while the first is in progress — you may reuse tokens across sessions or interleave steps from two flows:

1. Start account upgrade flow (session A) — get token X.
2. Start account upgrade flow (session B) — get token Y.
3. Submit token X to session B’s endpoint → unexpected privilege.

---

Pattern 8: Trusting User-Supplied Role or Status

Look for any parameter that specifies your role, account type, or status:

POST /register HTTP/1.1

username=attacker&password=test&role=admin

{"username": "attacker", "isAdmin": true}

Or in the checkout flow:

accountType=premium

Modify and observe if the server grants the specified privilege.

---

Pattern 9: Abusing Error Handling

If an action partially executes before throwing an error:

1. Trigger the action with invalid data that causes an error mid-way.
2. Check if the first half of the state change persisted (e.g., balance deducted but transfer not sent).

Also test: what if you interrupt the flow (close connection, send malformed data at step 2)?

---

Pattern 10: Forced Browsing to Admin Endpoints

Try accessing admin functionality directly, using common paths:

/admin
/admin/users
/admin/deleteUser?id=1
/dashboard/admin
/manage
/internal

Vary the Cookie and Role headers. Sometimes the front-end enforces authorization but the back-end endpoint does not.

---

Burp Suite workflow

1. Proxy — browse every app function with logging enabled; note every state-changing request.
2. Repeater — replay requests with modified parameters: negative values, large numbers, skipped steps, repeated submissions.
3. Intruder — fuzz numeric parameters for overflows and boundary values.
4. Sequencer — check if tokens (discount codes, order IDs, CSRF tokens) are predictable.
5. Comparer — compare responses between a legitimate request and a modified one to spot logic differences.
6. Burp Logger — review full request/response history to spot partial state changes in error paths.