KagisoSec_
Web
WEB

Parameter Logic Bugs

CWEE parameter logic bug taxonomy: unexpected input manipulation (negative prices, oversized quantities), null safety exploitation (missing null checks), validation logic disparity (front-end vs back-end), and whitebox code review methodology.

web logic-bugs parameter-manipulation null-safety whitebox cwee

What are Parameter Logic Bugs

Parameter logic bugs occur when applications fail to properly validate or handle edge cases in parameter values. Unlike injection attacks, these don’t require special characters — they exploit the application’s own logic using legitimate (but unexpected) input values.

CWEE identifies three primary types:

  1. Unexpected Input — application doesn’t handle edge case values (negative, zero, maximum, special strings)
  2. Null Safety — missing null/undefined checks cause unintended code paths
  3. Validation Logic Disparity — front-end validates but back-end doesn’t (or vice versa)

Type 1: Unexpected Input

What to test

For every numeric parameter: negative, zero, maximum integer, decimal, float, scientific notation. For every string parameter: empty string, null/undefined, very long string, HTML, special chars, Unicode. For every ID parameter: 0, -1, 9999999, other users’ IDs.

Attack 1 — Negative price / quantity

POST /checkout
item=shirt&quantity=-5&price=10.00

If the app calculates total = quantity * price without range validation → total is -$50.00 → balance increases.

Or:

POST /apply-discount
discount_percent=110

If 110% discount is accepted → item costs negative amount.

Attack 2 — Zero-price bypass

POST /purchase
item_id=premium_plan&price=0.00

If the server trusts the client-supplied price.

Attack 3 — Integer overflow

POST /transfer
amount=2147483648

If the amount is stored as a 32-bit signed integer: 2^31 = 2147483648 wraps to -2147483648 → negative transfer → balance increases.

POST /buy
quantity=9999999999999999

Overflow to a very small or negative number after arithmetic.

Attack 4 — Maximum value bypass

POST /vote
score=9999999

If there’s no max validation → inject an impossibly high score.

Attack 5 — Step 0 in checkout (skip steps)

POST /checkout/step/0

If workflow steps are numbered and you can request step 0 (or negative steps):

GET /checkout?step=-1
POST /admin/complete_order?step=99

Attack 6 — Unexpected string in numeric field

quantity=abc    → server may default to 0 or null
quantity=true   → true in JSON is 1 in some type coercions
quantity=[]     → array in PHP count = 0
quantity={}     → object

Type 2: Null Safety

What to test

Submit requests with missing parameters or null values:

# Missing parameter
POST /login
username=admin   (no password field)

# Explicit null (JSON)
{"username": "admin", "password": null}

# Empty string
{"username": "", "password": ""}

# PHP: submit array
password[]=anything

Attack 1 — Missing parameter causes null bypass

// Vulnerable code
$token = $_GET['token'];  // null if not provided
if ($token == $expected_token) {  // null == null → true!
    grant_access();
}

Submit the request without the token parameter → both sides are null → null == null is true → access granted.

Attack 2 — Null in JWT/session comparison

{"alg": "HS256", "typ": "JWT"}
{"username": "admin", "role": null}

If the backend checks if (role === 'user') and null passes none of those checks → may default to admin behaviour.

Attack 3 — Null in optional parameter escalation

POST /update-profile
username=alice&email=alice@example.com
# Omit the 'role' parameter entirely

If the backend only updates fields that are present in the request and omits null-checking, the role field may be left unchanged — or if it defaults to a higher privilege on null.

Attack 4 — Null safety in database query

// Vulnerable
$user_id = $_GET['id'];  // null if not provided
$query = "SELECT * FROM users WHERE id = $user_id";
// Becomes: SELECT * FROM users WHERE id =   → syntax error or all rows

Type 3: Validation Logic Disparity

What to test

Any validation that happens client-side but might not happen server-side (or vice versa):

  • Client-side JS validation of form fields
  • HTML min/max/maxlength attributes
  • Frontend-only price/quantity calculations
  • “Coming soon” or disabled UI elements

Attack 1 — Client-side field validation bypass

The HTML form has min="0" max="100":

<input type="number" name="quantity" min="0" max="100">

In Burp Repeater, send the raw HTTP request with quantity=99999 — server never re-validates the HTML constraints.

Attack 2 — Disabled field bypass

The UI disables a “price” field with disabled:

<input type="hidden" name="price" value="29.99" disabled>

In Burp, intercept the POST request and modify price=0.01 — the disabled attribute is client-only; the server receives whatever you send.

Attack 3 — Pre-release product access

# Button is hidden until launch date (client-side JS check)
GET /api/products/unreleased-item-id/purchase

# Modify productId in cart request to the unreleased item's ID
POST /cart/add
productId=UNRELEASED_ID&quantity=1

Attack 4 — Regex difference

Client validates email with a loose regex, server uses strict regex — or vice versa:

# Frontend accepts: user+tag@domain.com
# Backend splits on '+' → stores 'user' only
# Registration: user+admin@domain.com → stored as user@domain.com
# Login: user@domain.com → matches the registration account

Whitebox Code Review Methodology

Step 1 — Identify all parameter intake points

grep -rn "\$_GET\|\$_POST\|\$_REQUEST\|request\.args\|request\.form\|req\.body\|req\.query" --include="*.php" --include="*.py" --include="*.js" .

Step 2 — Trace each parameter to its use

For each parameter, follow the data flow:

  1. Is it validated before use? Where?
  2. Is validation on the server side or just client side?
  3. What are the edge cases the validation doesn’t handle?

Step 3 — Look for null checks

# PHP: check for missing null/empty checks
grep -rn "isset\|empty\|is_null\|!=" --include="*.php" . | grep -v "//.*isset"

# JS: missing null checks
grep -rn "\.length\|typeof\|=== undefined\|=== null" --include="*.js" .

Step 4 — Check arithmetic operations

grep -rn "\* \|\/ \|\+ \|\- \|total\|price\|amount\|balance\|quantity" --include="*.php" --include="*.py" . | grep -v "//"

Step 5 — Test boundary conditions

For every numeric parameter found:

TestValue
Minimum boundary0
Negative-1
Large value2147483647
Overflow2147483648
Float0.0001
Scientific notation1e10
Missing(omit the parameter)
Nullnull (JSON), empty string

Burp Suite workflow

  1. Proxy — intercept every business-logic request (checkout, transfer, purchase, vote).
  2. Repeater — manually modify parameter values to edge cases (negative, null, oversized).
  3. Intruder — in Sniper mode, fuzz a single numeric parameter with a numbers wordlist (-1000 to 1000).
  4. DOM Invader — check what validation exists in client-side JavaScript before submission.
  5. For whitebox: grep source for numeric operations and follow the data to find missing server-side validation.