Probleemi tuum seisneb selles, et esi- ja taustaprogrammid pakuvad sageli HTTP-protokolli erineval tasemel tuge, kuid samal ajal kapseldavad erinevate kasutajate päringud ühisesse kanalisse. Frontendi vastuvõtupäringute ja taustatöötluspäringute ühendamiseks luuakse pikaealine TCP-ühendus, mille kaudu edastatakse kasutajate päringuid, mis edastatakse ahelas üksteise järel, eraldatuna HTTP-protokolli abil. Päringute eraldamiseks lisatakse päised "Sisu pikkus" (määrab päringus olevate andmete kogumahu) ja "
Probleem tekib siis, kui kasutajaliides toetab ainult "Content-Length"-i, kuid ignoreerib "Transfer-Encoding: chunked" (näiteks Akamai CDN tegi seda) või vastupidi. Kui Transfer-Encoding: chunked on toetatud mõlemal küljel, saab rünnakuks kasutada HTTP päiseparserite rakendusfunktsioone (näiteks kui esiots eirab selliseid ridu nagu "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked ”, „Transfer-Encoding” :[tab]tükitud”, „X: X[\n]Edastuskodeering: tükeldatud”, „Edastuskodeering[\n]: tükeldatud” või „Edastuskodeering : tükeldatud” ja taustaprogramm töötleb neid edukalt).
Sel juhul võib ründaja saata päringu, mis sisaldab nii päist "Content-Length" kui ka "Transfer-Encoding: chunked", kuid suurus jaotises "Content-Length" ei vasta tükeldatud ahela suurusele, mis on tegelikust väärtusest väiksem. Kui kasutajaliides töötleb ja edastab päringu vastavalt "Sisu pikkusele" ja taustaprogramm ootab ploki lõpuleviimist "Transfer-Encoding: chunked" alusel, siis "Transfer-Encoding: chunked" põhinevate andmete lõpp määrata varem ja päringu järelejäänud saba asub ründaja järgmise päringu alguses, st. ründaja saab järgmisena edastatava kellegi teise päringu algusesse lisada suvalisi andmeid.
Kasutatud esiosa-taustaprogrammi kombinatsiooni probleemi kindlakstegemiseks saate esiprogrammi kaudu saata sellise päringu:
POST / HTTP kohta/1.1
Host: example.com
Edastus-kodeering: tükeldatud
Content-Length: 4
1
Z
Q
Probleem ilmneb siis, kui taustaprogramm ei töötle päringut kohe ja ootab tükeldatud andmete lõpliku nullpiirdeploki saabumist. Täielikumaks kontrolliks
Reaalse rünnaku läbiviimine sõltub rünnatava saidi võimalustest, näiteks Trello veebirakendust rünnates saab päringu alguse asendada (asendusandmed nagu “PUT /1/members/1234... x=x&csrf =1234&kasutajanimi=testzzz&bio=cake) ja saatke sõnum, mis sisaldab kolmanda osapoole kasutaja algset taotlust ja selles määratud autentimisküpsist. Saas-app.com-i rünnaku puhul osutus võimalikuks JavaScripti koodi asendamine vastuses, asendades selle ühes päringu parameetritest. Redhat.com-i rünnaku puhul kasutati sisemist töötlejat, et suunata ümber ründaja veebisaidile (päring vormis „POST /search?dest=../assets/idx?redir=//[meiliga kaitstud]/ HTTP/1.1").
Sisu edastamise võrkude meetodi kasutamine võimaldas soovitud saidi lihtsalt asendada, asendades päise „Host:”. Rünnakut saab kasutada ka sisu vahemällu salvestamise süsteemide sisu mürgitamiseks ja vahemällu salvestatud konfidentsiaalsete andmete eraldamiseks. Meetodi tipp oli PayPali vastu suunatud ründe korraldamine, mis võimaldas pealt kuulata kasutajate poolt autentimise ajal saadetud paroole (iframe'i päringut muudeti JavaScripti käivitamiseks lehe paypal.com/us/gifts kontekstis, millist CSP-d (sisu turvapoliitikat) ei rakendatud).
Huvitaval kombel oli 2005. aastal
Allikas: opennet.ru