HTTP Parameter Pollution (HPP) - Parameter-Verschmutzung

Summary: HTTP parameter pollution occurs when multiple parameters with the same name are sent in an HTTP request and backend systems interpret them differently. Attackers can use this to bypass validation logic, circumvent WAF rules, and trigger unexpected behavior. Affected: Parameter parsing in PHP (last value), ASP.NET (first value), Node.js (array) - the inconsistency between components is exploited.

HTTP Parameter Pollution (HPP) arises from a quirk of the HTTP standard: there is no normative specification on how web servers should handle duplicate query or body parameters with the same name. Different technologies handle this problem differently - and it is precisely this inconsistency that attackers exploit.

Basic Principle

What happens with ?id=1&id=2? Different frameworks handle duplicate parameters differently:

The inconsistency IS the problem, not a bug in a single component!

Typical HPP attack vectors:

• Query parameters in GET requests: ?role=user&role=admin
• POST body parameters: username=victim&username=attacker
• HTTP header values (less common, but possible)
• JSON arrays in request bodies (JSON HPP)
• SOAP envelopes with duplicate elements

HPP attack vectors

Attack 1 - WAF Bypass:

The WAF checks /search?q=SELECT+*+FROM+users and blocks it. HPP bypass splits the payload: /search?q=SELECT+*&q=FROM+users - the WAF checks only the first parameter, but the backend concatenates both values. A SQLi payload like ?q=1' OR '1'='1 is also blockable, but ?q=1'&q=OR '1'='1 splits it so the WAF does not see the complete payload while the backend combines it.

Attack 2 - Signature Verification Bypass:

Typical secure payment API: POST /transfer with body amount=100&to=alice&signature=HMAC(amount=100,to=alice). HPP attack body: amount=100&to=alice&signature=VALID_HASH&to=attacker. The signature verification takes the FIRST "to" value (alice - valid!), while the transfer logic takes the LAST "to" value (attacker). Result: valid transfer to the wrong recipient!

Attack 3 - Access Control Bypass (IDOR):

Normal request: GET /api/order?user_id=123&status=pending. HPP bypass: GET /api/order?user_id=123&user_id=456&status=pending. If the authorization layer checks 123 (first value) but the data query runs with 456 (last value) - IDOR: third-party orders become accessible!

Attack 4 - Logic Manipulation (Order Process):

Coupon application: POST /checkout with body item_id=EXPENSIVE&coupon=INVALID&coupon=VALID50. Coupon validation checks the first value (INVALID - no discount), but price calculation uses the last value (VALID50 - 50% discount). Result: discount applied without a validated coupon!

Attack 5 - Server-Side HPP (SSHPP):

The backend aggregates URLs for external API calls. User input lang=en produces https://api.intern/data?id=1&lang=en. If the attacker submits &id=MALICIOUS&lang=en, the full URL becomes https://api.intern/data?id=1&id=MALICIOUS&lang=en - the internal parameter gets overwritten!

Detection in the Penetration Test

1. Parameter Identification: List all parameters in GET, POST, cookies, and headers. Tip: Burp Suite "Param Miner" Extension.

2. Duplication Tests (for each parameter):

• Original: ?param=ORIGINAL
• HPP Test: ?param=ORIGINAL&param=INJECTED
• Reverse order: ?param=INJECTED&param=ORIGINAL
• Comma notation: ?param=ORIGINAL,INJECTED
• Array notation: ?param[]=ORIGINAL&param[]=INJECTED

3. Behavior analysis:

• Does the app respond differently with duplicated parameters?
• Which value is actually processed?
• Are there differences between the validation and processing layers?

4. WAF bypass test:

• Create a known WAF block (simple SQLi/XSS payload)
• Split the payload across two parameters
• Test various combinations
• Also use array syntax: ?q[]=SELECT&q[]=*

5. Automated (Burp Active Scan): Parameter duplication is detected by Burp Pro. "Passive Scans" often reveal HPP clues in response differences. HPP Finder Extension available in the BApp Store.

6. JSON HPP:

{"user": "alice", "user": "attacker"}

Which implementation takes which value? JavaScript parsers typically use the last value. Check for "god mode" via JSON duplicates.

Mitigation Measures

1. Consistent parameter extraction:

• Use ONLY one method for parameter extraction
• Explicitly decide: first or last value?
• NEVER rely on implicit framework behavior!

Python (Flask) - safe:

value = request.args.get('param')          # first value
values = request.args.getlist('param')     # all values
# If getlist returns more than 1 element -> 400 Bad Request!

Node.js (Express) - safe:

const param = req.query.param;
if (Array.isArray(param)) {
  return res.status(400).json({ error: 'Duplicate parameter' });
}

2. Duplicate rejection: Middleware that blocks duplicate parameters, returning 400 Bad Request.

Nginx (rudimentary):

if ($args ~* "(.+)=(.*)&\1=") {
  return 400;
}
# Warning: Check Regex performance!

3. Consistency between layers:

• Security checks (WAF/Auth) and the application MUST use the same parameter semantics
• Single source of truth for parameter parsing
• Same library/method for WAF bypass checks and business logic

4. Input whitelisting:

• Explicitly define expected parameters
• Discard unknown parameters (do not ignore them!)
• Validate number of parameters: max. 1 per known name

5. Signature and integrity checks:

• Calculate HMAC using exactly serialized parameters
• Canonical serialization: alphabetically sorted key=value pairs
• Signature verification and processing MUST use the same canonical form

6. WAF configuration:

• Enable HPP detection in the WAF (ModSecurity: CRS HPP rules)
• Enable REQUEST_ARGS:duplicate rules
• Perform periodic bypass tests against your own WAF!

---

HPP is one of the most frequently overlooked classes of vulnerabilities - because it often arises only through the interaction of multiple components. SSHPP attacks, in which an attacker-controlled parameter overwrites internal API parameters, are particularly dangerous. AWARE7 checks for HPP vulnerabilities during web application penetration tests as part of input validation testing.