http-parameter-pollution

SKILL: HTTP Parameter Pollution (HPP)

AI LOAD INSTRUCTION: Model the full request path: browser → CDN/WAF → reverse proxy → app framework → business code. Duplicate keys (a=1&a=2) are not an error at HTTP level; each hop may pick first, last, join, or array-ify. Test HPP when WAF and app disagree, or when internal HTTP clients rebuild query strings. Routing note: when the same parameter appears multiple times, or WAF/backend stacks differ, use the Section 1 matrix to test first/last/merge assumptions, then design Section 3 scenario chains.

0. QUICK START

Hypothesis: the security check reads one occurrence of a parameter while the action reads another.

First-pass payloads

id=1&id=2
id=1&id=1%20OR%201=1
url=https://legit.example&id=https://evil.example
amount=1&amount=9999
csrf=TOKEN_A&csrf=TOKEN_B
user=alice&user=admin

Body variants (repeat for POST)

application/x-www-form-urlencoded
id=1&id=2

multipart/form-data
------boundary
Content-Disposition: form-data; name="id"
1
------boundary
Content-Disposition: form-data; name="id"
2

Quick methodology

1. Fingerprint front stack (CDN/WAF) vs origin (language/framework) using baseline a=1&a=2.
2. Send both orders: a=1&a=2 and a=2&a=1 (some parsers are order-sensitive).
3. If JSON: test duplicate keys and Content-Type confusion (see Section 2).

1. SERVER BEHAVIOR MATRIX

Typical defaults — always confirm; middleware and custom parsers override these.

Why it matters: a WAF on IIS might see 1,2 while PHP backend receives 2 only — or the reverse if a proxy normalizes.

2. PAYLOAD PATTERNS

2.1 Basic duplicate key

2.2 Array-style (PHP / some frameworks)

2.3 Mixed array + scalar

2.4 Encoded ampersand (parser differential)

2.5 Nested / bracket keys

2.6 JSON duplicate keys

Many parsers keep last key; some keep first. JavaScript JSON.parse keeps the last duplicate key.

3. ATTACK SCENARIOS

3.1 HPP + WAF bypass

Pattern: WAF inspects first value; application uses last.

Also try: benign value in JSON field duplicated in query string, if gateway merges sources differently.

3.2 HPP + SSRF

Pattern: validator reads safe URL; fetcher reads internal/evil URL.

Confirm which component (library vs app) consumes which occurrence.

3.3 HPP + CSRF

Pattern: duplicate anti-CSRF token so one copy satisfies parser A and another satisfies parser B.

Use only in authorized CSRF assessments with a clear state-changing target.

3.4 HPP + business logic (e.g. payment)

Pair with race conditions or server-side rounding for higher impact; HPP alone often needs a split interpretation across layers.

4. TOOLS

Tip: log raw query strings at the app if you control a test lab; some frameworks expose only the “winning” value while logs show the full string.

5. DECISION TREE

Safety & scope: HPP testing can change server state (payments, account settings). Run only where explicitly authorized, with scoped accounts, and document parser behavior before high-impact requests.