Parameter Pollution | JSON Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
HTTP Parameter Pollution (HPP) è una tecnica in cui gli attaccanti manipolano i parametri HTTP per cambiare il comportamento di un'applicazione web in modi non intenzionati. Questa manipolazione avviene aggiungendo, modificando o duplicando i parametri HTTP. L'effetto di queste manipolazioni non è direttamente visibile all'utente, ma può alterare significativamente la funzionalità dell'applicazione sul lato server, con impatti osservabili sul lato client.
Un URL di transazione di un'applicazione bancaria:
URL originale: https://www.victim.com/send/?from=accountA&to=accountB&amount=10000
Inserendo un ulteriore parametro from
:
URL manipolato: https://www.victim.com/send/?from=accountA&to=accountB&amount=10000&from=accountC
La transazione potrebbe essere erroneamente addebitata a accountC
invece di accountA
, dimostrando il potenziale dell'HPP di manipolare transazioni o altre funzionalità come il ripristino della password, le impostazioni 2FA o le richieste di chiavi API.
Il modo in cui i parametri vengono analizzati e prioritizzati dipende dalla tecnologia web sottostante, influenzando come l'HPP può essere sfruttato.
Strumenti come Wappalyzer aiutano a identificare queste tecnologie e i loro comportamenti di parsing.
Caso di manipolazione OTP:
Contesto: È stata sfruttata una meccanismo di login che richiede una Password Usa e Getta (OTP).
Metodo: Intercettando la richiesta OTP utilizzando strumenti come Burp Suite, gli attaccanti hanno duplicato il parametro email
nella richiesta HTTP.
Risultato: L'OTP, destinato all'email iniziale, è stato invece inviato al secondo indirizzo email specificato nella richiesta manipolata. Questo difetto ha consentito l'accesso non autorizzato eludendo la misura di sicurezza prevista.
Questo scenario evidenzia una grave svista nel backend dell'applicazione, che ha elaborato il primo parametro email
per la generazione dell'OTP ma ha utilizzato l'ultimo per la consegna.
Caso di manipolazione della chiave API:
Scenario: Un'applicazione consente agli utenti di aggiornare la propria chiave API tramite una pagina delle impostazioni del profilo.
Vettore di attacco: Un attaccante scopre che aggiungendo un ulteriore parametro api_key
alla richiesta POST, può manipolare l'esito della funzione di aggiornamento della chiave API.
Tecnica: Utilizzando uno strumento come Burp Suite, l'attaccante crea una richiesta che include due parametri api_key
: uno legittimo e uno malevolo. Il server, elaborando solo l'ultima occorrenza, aggiorna la chiave API al valore fornito dall'attaccante.
Risultato: L'attaccante ottiene il controllo sulla funzionalità API della vittima, potenzialmente accedendo o modificando dati privati in modo non autorizzato.
Questo esempio sottolinea ulteriormente la necessità di una gestione sicura dei parametri, specialmente in funzionalità critiche come la gestione delle chiavi API.
Il modo in cui le tecnologie web gestiscono i parametri HTTP duplicati varia, influenzando la loro suscettibilità agli attacchi HPP:
Flask: Adozione del primo valore del parametro incontrato, come a=1
in una stringa di query a=1&a=2
, privilegiando l'istanza iniziale rispetto ai duplicati successivi.
PHP (su Apache HTTP Server): Al contrario, privilegia l'ultimo valore del parametro, optando per a=2
nell'esempio fornito. Questo comportamento può facilitare involontariamente gli exploit HPP onorando il parametro manipolato dall'attaccante rispetto all'originale.
I risultati sono stati presi da https://medium.com/@0xAwali/http-parameter-pollution-in-2024-32ec1b810f89
Ignora tutto dopo %00 nel nome del parametro.
Gestisce name[] come array.
_GET non significa metodo GET.
Preferisce l'ultimo parametro.
Usa i delimitatori & e ; per separare i parametri.
Non riconosce name[].
Preferisce il primo parametro.
POST RequestMapping == PostMapping & GET RequestMapping == GetMapping.
POST RequestMapping & PostMapping riconoscono name[].
Preferisce name se name E name[] esistono.
Concatenare i parametri e.g. first,last.
POST RequestMapping & PostMapping riconoscono i parametri di query con Content-Type.
Riconosce name[].
Concatenare i parametri e.g. first,last.
NON riconosce name[].
Preferisce il primo parametro.
NON riconosce name[].
Preferisce il primo parametro.
NON riconosce name[].
Preferisce l'ultimo parametro.
NON riconosce name[].
Preferisce l'ultimo parametro.
Il front-end potrebbe credere alla prima occorrenza mentre il backend utilizza la seconda occorrenza della chiave.
Alcaratteri non verranno interpretati correttamente dal frontend, ma il backend li interpreterà e utilizzerà quelle chiavi, questo potrebbe essere utile per bypassare certe restrizioni:
Nota come in questi casi il front end potrebbe pensare che test == 1
e il backend penserà che test == 2
.
Questo può anche essere usato per bypassare le restrizioni sui valori come:
Qui utilizzeremo il serializer di ciascun parser per visualizzare il rispettivo output.
Serializer 1 (ad esempio, la libreria GoJay di GoLang) produrrà:
description = "Duplicate with comments"
test = 2
extra = ""
Serializer 2 (ad esempio, la libreria JSON-iterator di Java) produrrà:
description = "Duplicate with comments"
extra = "/*"
extra2 = "*/"
test = 1
In alternativa, l'uso diretto dei commenti può essere altrettanto efficace:
La libreria GSON di Java:
La libreria simdjson di Ruby:
Il numero
può essere decodificato in più rappresentazioni, inclusi:
Which might create inconsistences
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)