HTTP Parameter Pollution (HPP)

HTTP Parameter Pollution (HPP) è una tecnica di attacco che sfrutta l’ambiguità nella gestione dei parametri duplicati nelle richieste HTTP. Lo standard HTTP non prescrive come un server deve comportarsi quando riceve lo stesso nome di parametro più volte nella stessa richiesta — e questa ambiguità crea superfici di attacco sfruttabili per aggirare controlli di sicurezza, manipolare la logica applicativa o provocare comportamenti inattesi.

La tecnica fu sistematizzata da Luca Carettoni e Stefano di Paola nel 2009.

Il problema dei parametri duplicati

Considera la richiesta:

GET /cerca?categoria=libri&categoria=elettronica HTTP/1.1

Il parametro categoria appare due volte. Come viene interpretato dipende interamente dalla tecnologia server:

Tecnologia	Comportamento
PHP / Apache	Usa l’ultimo valore: `elettronica`
ASP.NET (IIS)	Concatena con virgola: `libri,elettronica`
JSP / Tomcat	Usa il primo valore: `libri`
Python (Flask/Django)	Di default usa il primo o l’ultimo (dipende dalla versione)
Node.js (Express / qs)	Crea un array: `['libri', 'elettronica']`
Ruby on Rails	Usa l’ultimo valore

Non esiste un comportamento universale: la stessa richiesta può produrre risultati radicalmente diversi su stack diversi.

Scenari di attacco

Aggiramento di un WAF

Un Web Application Firewall ispeziona i parametri della richiesta per bloccare payload malevoli. Se il WAF analizza il primo parametro e il backend usa il secondo, l’attaccante può dividere il payload in due parametri:

POST /login HTTP/1.1
username=admin&password=safe_value&password=' OR '1'='1

Se il WAF legge il primo password (valore sicuro) ma il backend usa l’ultimo (' OR '1'='1), il payload di SQL Injection supera il filtro.

Manipolazione della logica applicativa

Un endpoint di trasferimento fondi espone:

POST /trasferisci
importo=100&destinatario=alice

Aggiungendo un secondo destinatario:

POST /trasferisci
importo=100&destinatario=alice&destinatario=evil_account

Se il layer di validazione usa alice e il layer di esecuzione usa evil_account, il trasferimento avviene verso il conto dell’attaccante.

HPP riflessa (lato client)

Se un’applicazione costruisce URL dinamicamente inserendo parametri utente in link, l’attaccante può iniettare parametri aggiuntivi che alterano il comportamento del link per altri utenti:

https://app.it/condividi?url=https://legittimo.it&url=https://evil.it

HPP su API di terze parti

L’applicazione firma una richiesta verso un’API verificando importo=100, ma poi aggiunge importo=0 come secondo parametro. Se l’API usa il secondo valore, il pagamento avviene a zero con firma valida.

HPP non si limita ai parametri GET. Può essere applicata a:

Corpi di richieste POST con Content-Type: application/x-www-form-urlencoded.
Header Cookie con valori duplicati.
Richieste JSON multilivello (con chiavi duplicate nello stesso oggetto JSON — comportamento non definito dalla specifica).

Contromisure

Normalizzazione input: scegliere esplicitamente come gestire i parametri duplicati (primo, ultimo, array, errore) e applicarlo uniformemente a tutti i layer.

Evitare la dispersione tra layer: il layer che valida i parametri deve essere lo stesso (o usare la stessa semantica) del layer che li utilizza.

Rifiuto dei duplicati: nelle API critiche, rispondere con errore 400 Bad Request se un parametro appare più di una volta.

WAF con piena consapevolezza HPP: i WAF moderni tentano di emulare il comportamento del backend per analizzare il valore che verrà effettivamente usato, non il primo che incontrano.

Uso di framework con comportamento prevedibile: preferire librerie di parsing che documentano esplicitamente come gestiscono i duplicati.

Relazione con altri attacchi

SQL Injection — HPP è spesso un vettore per bypassare le difese che proteggono da SQL Injection e altri attacchi di injection.
SSRF — HPP può essere usata per manipolare URL costruiti dinamicamente e indirizzarli verso destinazioni interne.
Vulnerabilità Informatica — HPP è classificata CWE-235 (Improper Handling of Extra Parameters).