HTTP Parameter Pollution for Authentication and Authorization Bypass

HTTP Parameter Pollution for Authentication and Authorization Bypass

HTTP Parameter Pollution gets taught with a reflected search query: send q=one&q=two and watch which value appears. The bounty-grade version targets an authorization decision. One component validates the first value while another acts on the last, joins both, or converts them into an array.

You are hunting parser disagreement across gateways, frameworks, signature middleware, and application code.

Fingerprint duplicate handling

Choose a harmless parameter and send duplicates:

• ?id=A&id=B
• Body: role=user&role=admin
• Query value plus body value with the same name
• Case changes such as tenantId and tenantid
• Bracket syntax: scope=user&scope[]=admin

Observe the response, not only what Burp displays. PHP often keeps the last scalar; some Java stacks keep the first; Node frameworks may expose an array; proxies may normalize before the app sees anything. JSON duplicate keys have similar ambiguity, though RFC behavior and parser implementations differ.

Build a small matrix: placement, order, response-selected value, and security outcome.

Authentication bypass patterns

Password reset and magic-link flows are rich targets. Imagine middleware validates email=victim@example.com but the mailer uses the last email=attacker@example.com. Or a signed request checks the first redirect_uri while OAuth logic follows the second.

Other high-signal parameters:

• user_id, account, or tenant beside a valid session
• role, isAdmin, or scope in invitations
• continue and redirect_uri after login
• OTP code paired with a phone or email identifier
• API signature fields included once in canonicalization and parsed differently later

Do not brute-force credentials. Two accounts let you prove the decision safely.

A clean two-account test

Create users A and B. Capture a request where B can modify B's profile. Duplicate the object selector so one value names B and the other names A. Reverse the order. If validation logs or response text says B while A's record changes, you have parser confusion with authorization impact.

For a login or reset flow, use two inboxes you own. Show that the security check binds to account A while the resulting token, redirect, or notification binds to B. Preserve every request byte; tooling may silently collapse duplicate fields when copying between tabs.

Cross-layer tricks

A WAF may inspect query parameters while the app prefers the body. An API gateway may merge both maps. Try Content-Type: application/x-www-form-urlencoded only where the endpoint normally accepts it. Switching content types and duplicate keys at once makes the root cause hard to prove.

Signed APIs deserve care. If canonicalization sorts or deduplicates parameters differently from the application parser, a valid signature may authorize a different action. Use your own API keys and low-risk resources. Never replay another user's signed request.

Separate quirks from findings

?page=1&page=2 returning page 2 is normal framework behavior. An auth bypass needs a trust decision made on one interpretation and a sensitive action made on another. A 500 from an array where code expected a string is input handling, usually low severity unless it creates reliable denial of service.

Report the direct control, polluted request, reversed-order result, and before/after account state. Name each parser layer if headers reveal it, but label inference as inference. Recommend rejecting duplicate security-sensitive parameters at the edge, parsing once into a typed structure, and using that same value for validation and action.

OWASP's HTTP Parameter Pollution testing guide is the baseline. Push past reflection: the payout appears when two parsers disagree about who is being authorized.