Burp AT trasforma una header injection in un desync sfruttabile

PortSwigger ha aggiunto a Burp AT una skill che eleva una HTTP request header injection a un CRLF-Powered Desync e può usarla per servire a utenti casuali un redirect verso il collaboratore dell’attaccante con un solo prompt¹. L’annuncio, pubblicato il 4 novembre 2026, introduce anche un nuovo controllo di scansione per HTTP Request Header Injection e la distillazione dell’approccio “CRLF-Powered Desync: Beheading HTTP Stream” direttamente in Burp AT¹.

La skill parte da una segnalazione di header injection rilevata da Burp Scanner. Esegue più fasi in autonomia, seguendo la metodologia interna del team. Opera in background, mentre il tester continua l’analisi manuale. Supporta qualsiasi punto di inserimento, non solo il path¹.

La prima fase stabilisce dove finisce l’iniezione a monte. PortSwigger nota casi in cui un’iniezione nel path viene riscritta in un header personalizzato upstream. Serve capire se l’header personalizzato viene inserito prima o dopo l’header Host. Il comportamento della risposta, per esempio un 400 dopo l’aggiunta di Host rispetto a una risposta “normale” senza, rivela l’ordine degli header e quindi il contesto dell’iniezione¹.

La seconda fase costruisce un payload di request splitting per provocare un desync. La skill prova prefissi e cerca di ottenere due o tre codici di stato distinti, segno che le richieste vengono modificate upstream. Gli esempi mostrati includono sequenze CRLF codificate come %0d%0a e un protocollo artificiale come “HTTP/13.37” tra i prefissi, usati per sondare come il server riscrive e interpreta la richiesta¹. Quando emergono stati differenti, la skill passa all’exploit.

La terza fase lancia un mini-crawl sul dominio bersaglio per individuare un “gadget” di redirect. Cerca reindirizzamenti che dipendono dall’header Host, dall’header X-Forwarded-Host o da URL assoluti. L’obiettivo è trovare un percorso che il server riallinei verso una destinazione calcolata a partire da un header controllabile¹.

La quarta fase combina la struttura di request splitting con il gadget di redirect. Se, per esempio, una richiesta a /assets viene riscritta in /assets/ usando l’Host per comporre la Location, la skill costruisce una sequenza che induce il backend a rispondere con un redirect verso il dominio del collaboratore. Invia più volte la richiesta su connessioni diverse. Se ottiene il redirect atteso, segnala l’issue con le evidenze raccolte¹.

PortSwigger spiega la scelta di un percorso di exploitation “prudente”. Ha valutato la Response Queue Poisoning, ma i test interni l’hanno giudicata troppo pericolosa per un uso automatico. Il redirect verso il collaboratore riduce i rischi per gli utenti reali e fornisce una prova d’impatto. La skill resta utile anche quando l’exploit pieno non è possibile: se il gadget manca, riporta un desync validato; se i prefissi non producono stati sufficientemente distinti, alza un’issue tentativo¹.

Per i casi ostinati, la pipeline copre edge case emersi nella ricerca. Una skill di fallback, CRLF-Powered Tunnelling, subentra quando il desync pieno fallisce e può far emergere bypass di controllo accessi. In assenza di esito, Burp AT prepara una sessione Intruder già popolata per proseguire con wordlist proprie¹.

Le skill sono abilitate di default. Alla prossima segnalazione di header injection, si può chiedere a Burp AT di tentare l’exploitation in autonomia. PortSwigger afferma di riversare in queste skill il know-how maturato in più cicli di ricerca, inclusi sei talk a BlackHat USA sul tema dello smuggling, per rendere pratiche tecniche appena pubblicate per chi testa ogni giorno¹. La stessa primitiva di redirect, se concatenata a cache poisoning, può spingere l’impatto fino al takeover dell’intero sito¹.