HTTP Request Smuggling

Guarda su YouTube → 26:33 29 giugno 2025

Descrizione

Oggi si parla di HTTP request smuggling, una vulnerabilità carina e sicuramente non banale. Iscriviti al patron per accedere al materiale dei video! - https://git.hexdump.sh I miei progetti: - https://esadecimale.it - https://hexdump.sh Per supportare il mio lavoro: - https://patreon.com/hexdump - https://buymeacoffee.com/hexdump - https://www.paypal.com/donate/?hosted_button_id=T49GUPRXALYTQ ------------------------- TIMESTAMP 00:00 HTTP Request Smuggling 07:30 CL.TE 16:00 TE.CL ------------------------- RIFERIMENTI - Lab 01: https://portswigger.net/web-security/request-smuggling/finding/lab-confirming-cl-te-via-differential-responses - Lab 02: https://portswigger.net/web-security/request-smuggling/finding/lab-confirming-te-cl-via-differential-responses

Commenti 11

I commenti vengono da YouTube e sono aggiornati periodicamente.

@medusa_x00 29 giugno 2025 1

Ciao, è una vulnerabilità che ho molto a cuore. Devo dire che l’hai spiegata bene, anche se il cl0 non è client come hai detto tu, forse ti confondevi con il csd (client side desync). Comunque avrei portato e analizzato dei casi reali per dare più impatto, come un mass redirect o steal di cookie anche http only con report pubblici di hackerone o nelle slide di kettle. Avrei anche spiegato la richiesta vittima che si appende alla seconda richiesta incompleta tua. Si, qui un’altra incorrettezza, la ‘seconda richiesta’ in realtà non è una seconda richiesta, ma l’inizio (e incompleta), della seconda richiesta, che la vittima completerà.
1 risposta
1. @esadecimale Autore 29 giugno 2025 1
  
  Sull'ultimo punto se non sbaglio lo menziono sicuramente in 22:56 per il calcolo del Content-Length, però si avrei dovuto dare più enfasi a questo aspetto Rispetto al cl0 e csd, si quello errore mio E rispetto ai casi reali, ottimo punto
@antonellocasu6578 30 giugno 2025 1

Smuggling "introdurre di nascosto o in modo illecito " (in questo caso due richieste, facendone sembrare una, eludendo il controllo del proxy/frontend/balancer o whatever)...Un termine legato al contrabbando sostanzialmente o al traffico clandestino. Ottima spiegazione Leonardo.
@Fede-pw8ky 2 marzo 2026

ottima spiegazione come sempre, vulnerabilià non facile e molto interessante..grazie Leo
@0xsweatta 29 giugno 2025 1

Vulnerabilità molto interessante
@giovannisardisco4541 29 giugno 2025

"Smaggle request" può essere tradotto come "richiesta clandestina". In effetti, rende bene l'idea, perché si infila clandestinamente in un'altra richiesta 😅
1 risposta
1. @esadecimale Autore 29 giugno 2025
  
  ahahah si, suona particolare in italiano xD
@Tulsayab 16 luglio 2025

mai fidarsi del frontend
1 risposta
1. @esadecimale Autore 19 luglio 2025
  
  mai fidarsi in generale 😂
@giovannisardisco4541 29 giugno 2025

Domanda: c'è modo di mitigare lato server questa vulnerabilità? Immagino che obbligare ad usare HTTP/2 potrebbe essere un modo, ma è una soluzione percorribile nel mondo reale? Altri modi di mitigare gli esempi che hai fatto vedere?
1 risposta
1. @esadecimale Autore 29 giugno 2025 1
  
  Dipende da come i server leggono gli header. Puoi anche forzare la presenza di un solo header, e se vedi entrambi blocchi la richiesta. Perché nasce da questa inconsistenza di lettura tra frontend server e backend server. Una conseguenza del fatto che in HTTP/1.1 ci sono diversi modi di specificare la lunghezza della richiesta (del body nello specifico) In HTTP/2.0 il modo di specificare il size è unico, non ci sono modi diversi se ricordo bene (non te lo confermo, da controllare), e quindi non hai problemi. Se entrambi sono HTTP/2.0, se invece il backend supporta HTTP/1.1 puoi comunque essere vulnerabile