Perché il browser mente: 6 trucchi sulle richieste che svelano bug nascosti

TL;DR

Il browser non è uno strumento di test di sicurezza. Sanifica il tuo input, segue i redirect per conto suo e ti mostra una pagina di errore pulita mentre scarta in silenzio gli stack trace, gli errori del database e i parametri nascosti che il server rispedisce indietro. Burp Suite ti mostra la verità grezza, e lo scarto tra le due è dove si nascondono i bug veri. Padroneggia questi 6 trucchi di manipolazione delle richieste HTTP e smetterai di tirare a indovinare se un target è sicuro per iniziare a leggere cosa ti dice davvero il server:

1. Leggi la risposta grezza che il browser nasconde (information disclosure).
2. Parameter tampering che innesca una error based SQL injection.
3. HTTP method tampering che aggira l'autenticazione.
4. Cambio di Content-Type che abilita il mass assignment.
5. Spoofing degli header IP che bypassa un 403.
6. Caccia ai parametri POST e PUT che il tuo URL non mostra mai.

Ogni trucco qui sotto arriva con la richiesta reale e la risposta reale, esattamente come lavoro io su un target.

Il browser sanifica tutto, ed è proprio questo il problema

La maggior parte dei principianti testa le applicazioni web digitando nei form del browser e guardando lo schermo. Buttano un singolo apice in una casella di ricerca, vedono un errore generico, decidono che il target è sicuro e passano oltre. È per questo che la maggior parte dei principianti non trova nulla.

Il browser fa un sacco di lavoro prima che il tuo input arrivi al server. Codifica i caratteri speciali, aggiunge header che non hai chiesto, segue i redirect in automatico e sostituisce i brutti errori del server con una pagina amichevole. Poi, quando la risposta torna indietro, un moderno frontend JavaScript fa il parsing del JSON e di solito ti mostra un solo campo, il message, ignorando tutto il resto. Il campo stack, l'errore del database, il dettaglio di debug: la pagina riceve tutto e sceglie di non mostrarne nulla.

Burp Suite non ha alcun frontend. Si frappone tra il tuo browser e il server come un proxy di intercettazione e ti mostra la richiesta completa e la risposta completa, byte per byte. Il server fa continuamente trapelare segreti in quelle risposte. È solo che il browser non te li passa. Imparare la manipolazione delle richieste HTTP significa imparare a leggere cosa dice il server quando smetti di lasciare che il browser traduca al posto tuo.

L'ho imparato a mie spese. All'inizio del mio percorso nel bug bounty ho passato mesi a testare attraverso il browser, trovavo un errore pulito su ogni pagina di login e marcavo un target dopo l'altro come sicuro. Così non ho trovato neanche un bug. Nel momento in cui ho iniziato a intercettare ogni richiesta e a leggere le risposte grezze, i miei risultati sono cambiati del tutto. Quell'abitudine è il modo in cui ho raggiunto oltre 250 menzioni nelle Hall of Fame di organizzazioni come OMS, UNESCO, BBC, Boeing e Cambridge, ed è così che mi sono aggiudicato la CVE-2025-56697.

1. Leggi la risposta grezza che il browser nasconde

Il primo trucco non è un payload. È un'abitudine: intercetta la richiesta, inviala e leggi l'intera risposta invece della pagina.

Stavo testando una pagina di login. Form standard, campo email, campo password, pulsante di accesso. Nel browser ho provato un singolo apice e un classico ' OR '1'='1-- nel campo email. Ogni volta, il browser rispondeva con la stessa riga pulita:

The email or password provided is incorrect.

Nessuno stack trace. Nessun indizio sul database. Niente. Un principiante legge questo e molla. Ed è esattamente lì che il target smette di parlare al browser e inizia a parlare a Burp Suite.

Ho attivato l'intercept e ho inviato lo stesso login con lo stesso payload. La richiesta sembrava ordinaria, una POST a /api/users/login. La risposta no:

HTTP/1.1 401 Unauthorized
Server: nginx
Content-Type: application/json; charset=utf-8

{
  "errors": [
    {
      "message": "The email or password provided is incorrect",
      "stack": "AuthenticationError: The email or password provided is incorrect.\n  at login (/home/app/node_modules/payload/dist/auth/operations/login.js:62:19)\n  at process.processTicksAndRejections (node:internal/process/task_queues:95:5)\n  at async loginHandler (/home/app/node_modules/payload/dist/auth/requestHandlers/login.js:20:24)"
    }
  ]
}

Il browser ha mostrato una riga. Burp Suite ha mostrato lo stack trace completo. In un solo login fallito ora sapevo che il server gira su Node.js, che l'applicazione usa il framework Payload, che il codice vive in /home/app/ e i file e i numeri di riga esatti dove avviene l'autenticazione.

Questa è la information disclosure, catalogata come CWE-200, e raramente è il bug finale. È ricognizione che il server ti regala gratis. Conoscere il framework ti permette di cercare vulnerabilità note. Conoscere i percorsi dei file ti permette di indovinare altri endpoint. Sapere che è Node.js ti dice quale sintassi di injection provare dopo. Il browser lo ha chiamato "una password errata". Il server lo ha chiamato un progetto dettagliato.

2. Parameter tampering: un apice, un errore SQL

Il parameter tampering è cambiare un valore di cui l'applicazione si fida e guardare cosa si rompe. Il mio esempio preferito da una sessione recente era una pagina di recensioni su un sito di e-commerce, quella con un semplice voto a pollice in su.

Ho cliccato su like e ho catturato la richiesta. Un corpo POST pulito:

POST /api/reviews/vote HTTP/2
Content-Type: application/x-www-form-urlencoded

reviewId=122825603&vote=1&apiKey=pubkey-XCodOia&sId=94323

La risposta era un ordinato {"voteUp":1,"voteDown":0}. Niente trapelava. La maggior parte dei tester passa oltre. Io invece ho guardato quel reviewId e mi sono posto l'unica domanda che conta: è numerico, quindi cosa succede se il backend costruisce una query SQL con esso e io invio qualcosa che non è un numero? Ho cambiato reviewId=122825603 in reviewId=122825603', un singolo apice, e l'ho rinviata.

La risposta è stata immediata e fragorosa:

HTTP/2 500 Internal Server Error
Content-Type: application/json

{
  "message": "An error has occurred.",
  "exceptionMessage": "The INSERT statement conflicted with the FOREIGN KEY constraint \"FK_dbo.ReviewVotes_dbo.Review_ReviewId\". The conflict occurred in database \"shopry_shopifyproductaddons\", table \"dbo.Review\", column 'Id'.",
  "exceptionType": "System.Data.SqlClient.SqlException"
}

Quel singolo carattere ha rivelato il motore del database (Microsoft SQL Server), il nome del database, la tabella Review, la colonna Id e una relazione di chiave esterna verso ReviewVotes. Questa è la classica disclosure da error based SQL injection, ed è la porta d'ingresso, non la destinazione. Ora conosco il motore, quindi conosco la sintassi. Conosco i nomi delle tabelle, quindi posso pensare a UNION SELECT. Conosco la struttura, quindi posso indovinare /api/reviews/delete e /api/reviews/edit. Il browser avrebbe intercettato quel 500 in JavaScript e mostrato "Qualcosa è andato storto". Burp Suite mi ha mostrato l'OWASP Web Parameter Tampering in una sola richiesta.

Già che sei in quel corpo, testa anche gli altri parametri. Gli ID numerici come reviewId sono anche candidati primari per IDOR e BOLA: inserisci l'ID di un altro utente e guarda di chi sono i dati che tornano. Un solo corpo di richiesta può nascondere tre diverse classi di bug.

3. HTTP method tampering per aggirare l'autenticazione

Alcuni controlli di accesso sorvegliano solo le porte che si aspettano tu usi. L'HTTP method tampering, detto anche verb tampering, testa le porte che hanno dimenticato.

Su un target un pannello di amministrazione restituiva 401 Unauthorized nel browser. La basic authentication era abilitata e le credenziali comuni non davano risultato. La maggior parte delle persone si ferma qui. Io ho catturato la richiesta e ho cambiato solo il metodo:

GET  /admin   ->  401 Unauthorized
POST /admin   ->  401 Unauthorized
HEAD /admin   ->  200 OK

HEAD ha restituito 200 OK. Il server ha elaborato la richiesta e l'ha considerata valida. OPTIONS e TRACE hanno fatto lo stesso. L'autenticazione era imposta per GET e POST e per nient'altro. La configurazione era più o meno così:

<Limit GET POST>
  require valid-user
</Limit>

Lo sviluppatore aveva dato per scontato che contassero solo GET e POST e aveva dimenticato che HEAD, OPTIONS, TRACE e PUT esistono. Cambiando un solo verbo in Burp Suite, sono arrivato al pannello senza credenziali. Questo è un caso da manuale di broken access control, il rischio numero uno della OWASP Top 10. Per un approfondimento sulla tecnica, il riferimento classico resta Tampering HTTP methods to bypass authentication, e la guida allo sfruttamento degli header di YesWeHack copre la famiglia più ampia.

4. Cambio di Content-Type e mass assignment

Le API moderne accettano più di un formato, e gli sviluppatori raramente li validano tutti allo stesso modo. Questo trucco concatena un cambio di Content-Type con il mass assignment per scalare i privilegi.

Stavo testando un endpoint di registrazione. Il form del browser mostrava tre campi, e la richiesta catturata era JSON pulito:

POST /api/auth/register HTTP/2
Content-Type: application/json

{ "username": "testuser", "email": "test@example.com", "password": "Test123!" }

Il server validava correttamente il JSON. Controllava il formato dell'email e sanificava contro il cross site scripting. Sembrava sicuro. Poi ho cambiato il Content-Type in application/xml e ho aggiunto un campo che il form non offriva:

POST /api/auth/register HTTP/2
Content-Type: application/xml

<?xml version="1.0"?>
<user>
  <username>testuser</username>
  <email>test@example.com</email>
  <password>Test123!</password>
  <role>admin</role>
</user>

Il parser XML non imponeva lo stesso schema, il campo extra <role> veniva legato direttamente all'oggetto utente e l'account veniva creato con privilegi di amministratore. Sono due bug in una sola richiesta: il cambio di Content-Type ha aggirato la validazione, e il mass assignment di un parametro nascosto ha scalato il privilegio. Il riferimento difensivo è l'OWASP Mass Assignment Cheat Sheet, e PortSwigger ha un lab pratico sul mass assignment se vuoi provarlo in sicurezza. Se testi spesso le API, la mia guida al testing di sicurezza delle API approfondisce i campi nascosti e la OWASP API Top 10.

5. Falsificare gli header IP per aggirare un 403

Quando un server limita un endpoint in base all'IP, di solito legge l'IP da un header, e gli header sono controllati dall'attaccante.

Ho trovato /api/admin/backup che restituiva 403 Forbidden con il messaggio "Access denied. Admin IP required". Il server stava controllando l'IP del client. Quindi gli ho detto cosa volevo che vedesse:

GET /api/admin/backup HTTP/2
Host: target.com
X-Forwarded-For: 127.0.0.1

La risposta è passata da 403 Forbidden a 200 OK, con il file di backup nel corpo. Il server si fidava di X-Forwarded-For per identificare il client senza verificare che l'header provenisse da un proxy fidato, quindi chiunque affermasse di essere 127.0.0.1 veniva trattato come localhost. Non era l'unico header che funzionava:

X-Real-IP: 127.0.0.1        ->  200 OK
X-Originating-IP: 127.0.0.1 ->  200 OK
X-Remote-IP: 127.0.0.1      ->  200 OK
X-Client-IP: 127.0.0.1      ->  200 OK

Questa è un'altra variante del broken access control, e un bypass del 403 affidabile da tenere nel kit. I trucchi su header e percorso come X-Original-URL e X-Rewrite-URL appartengono allo stesso set di test. La community mantiene una solida lista aggiornata in PayloadsAllTheThings, che vale la pena tenere aperta mentre lavori.

6. Va' a caccia dei parametri che il tuo URL non mostra mai

Ecco l'intuizione che lega insieme tutte le altre. Quando leggi la barra degli indirizzi, vedi solo i parametri GET:

https://target.com/search?q=test&page=1

Ma le applicazioni moderne svolgono il loro lavoro sensibile nelle richieste POST e PUT, e quei parametri vivono nel corpo, invisibili all'URL. Guarda di nuovo la richiesta di voto del trucco 2:

reviewId=122825603&vote=1&apiKey=pubkey-XCodOia&sId=94323

Se ti limitassi a guardare la barra degli indirizzi del browser, vedresti https://target.com/reviews e nient'altro. Nessun reviewId, nessun apiKey, nessun sId. Tutto si nasconde nel corpo, e il corpo è esattamente dove viveva la SQL injection. Poiché questi parametri non compaiono mai nell'URL, gli sviluppatori spesso danno per scontato che nessuno li veda e li validano in modo lasco. Burp Suite li vede tutti, e così fanno gli attaccanti.

Quindi cattura tutto, non solo l'URL. Clicca ogni pulsante, scatena ogni evento JavaScript e guarda la cronologia del proxy riempirsi di endpoint che la documentazione non ha mai menzionato. Leggere il traffico grezzo è la stessa disciplina che rende Wireshark e Nmap degni di essere imparati: la verità è sul filo, non sullo schermo.

La metodologia in 5 passi che eseguo su ogni target

Questi trucchi non sono fortuna. Sono un sistema. Ecco il ciclo che eseguo su ogni target prima di inseguire qualunque vulnerabilità specifica, e funziona altrettanto bene in un home lab quanto su un programma reale.

Primo, mappa tutte le funzionalità. Passa la prima ora usando l'applicazione come un utente vero. Clicca tutto, invia ogni form, cambia ogni impostazione e lascia che la cronologia di Burp Suite registri ogni endpoint, inclusi quelli innescati da JavaScript che nessuna documentazione elenca.

Secondo, individua i parametri interessanti. Gli ID numerici (userId, orderId) sono candidati per la SQL injection e l'IDOR. I flag booleani (isAdmin=false, verified=no) chiedono solo di essere ribaltati. Le chiavi API, i parametri di azione come action=delete e i campi nascosti meritano tutti attenzione.

Terzo, testa ogni parametro singolarmente. Non spruzzare payload. Cambia un valore alla volta. Per i campi numerici, prova un singolo apice, un numero negativo, uno zero, un numero enorme e l'ID di un altro utente. Per le stringhe, prova un apice, un backslash, un null byte e ../../etc/passwd. Per i booleani, ribaltali, rimuovili e cambiane il tipo.

Quarto, testa metodi HTTP e header. Per ogni endpoint interessante, passa in rassegna GET, POST, PUT, DELETE, HEAD, OPTIONS e TRACE, poi prova X-Forwarded-For, X-Real-IP e X-Original-URL su qualunque cosa sia limitata.

Quinto, osserva le risposte con attenzione. Il server ti dice tutto, se sai ascoltare. Leggi i messaggi di errore e gli stack trace, confronta le lunghezze delle risposte, nota le differenze di timing e fai attenzione agli status code. Un 401 non è un 403 non è un 500, e ognuno significa qualcosa di diverso su come è stato gestito il tuo input.

Quel ciclo è il cuore del vero penetration testing delle applicazioni web, ed è esattamente il flusso di lavoro che alleniamo nel bootcamp di cybersecurity di Unihackers. Se vuoi applicarlo su programmi reali, parti dalla mia guida su come scegliere il tuo primo target bug bounty.

Domande frequenti

Queste corrispondono alle domande che i neofiti pongono più spesso, e sono scritte per reggersi da sole.

Cos'è la manipolazione delle richieste HTTP? È intercettare una richiesta dopo che il browser l'ha costruita e modificarne parti che il browser non ti lascerebbe mai toccare: i parametri del corpo, il metodo, gli header e il Content-Type. Leggi la risposta grezza per vedere cosa fa davvero il server con il tuo input.

Perché trovare bug in questo modo invece che nel browser? Perché il browser nasconde le prove. Mostra un amichevole message e scarta lo stack trace, l'errore del database e i campi nascosti. Il proxy mostra la verità non filtrata, e il bug vive nella differenza.

Conclusione

La manipolazione delle richieste HTTP non riguarda il memorizzare diecimila payload. Riguarda la curiosità. Guardi una richiesta, ti chiedi perché esista un parametro e scopri cosa dice il server quando lo confondi di proposito. Il browser è costruito per gli utenti: sanifica, nasconde e abbellisce. Burp Suite è costruito per la verità: ti mostra esattamente cosa pensa il server.

Quindi la prossima volta che testi un target, non fidarti dello schermo. Intercetta tutto, modifica ogni parametro, invia valori strani, cambia il metodo, cambia il Content-Type e aggiungi l'header inaspettato. Poi leggi la risposta grezza. I segreti sono già lì. Devi solo smettere di lasciare che il browser ti menta.

Continua a cacciare. Resta curioso. E ricorda: il browser mente, Burp Suite dice la verità.