http-parameter-pollution

HTTP Parameter Pollution (HPP): duplicate query/body keys parsed differently by servers, proxies, WAFs, and app frameworks. Use when filters and application layers disagree on which value wins, enabling bypass, SSRF second URL, logic abuse, or CSRF token confusion.

By yaklang · 3,012 installs

npx skills add yaklang/hack-skills --skill http-parameter-pollution

Source repository · Upstream listing

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 Body variants (repeat for POST) 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. Technology Behavior Example: a=1&a=2 PHP / Apache ( $ GET ) Last occurrence a=2 ASP.NET / IIS Often comma joined (all) a=1,2 JSP / Tomcat (servlet param) First occurrence a=1 Python / Django ( QueryDict ) Last occurrence a=2 Python / Flask ( request.args ) First occurrence a=1 Node.js / Express ( req.query ) Array of values a=['1','2'] (shape may vary by parser version) Perl / CGI First occurrence a=1 Ruby / Rack (Rack::Utils) Last occurrence a=2 Go net/http ( ParseQuery ) First occurrence a=1 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 Tool How to use Burp Suite Repeater: duplicate keys in raw query/body; Param Miner / extensions for hidden params; compare responses for first vs last interpretation OWASP ZAP Manual Request Editor; Automated Scan may not deeply fuzz HPP — prefer manual variants Custom scripts Build exact raw HTTP (preserve ordering) — some clients normalize duplicates 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.