Kjarni vandans er sá að framenda og bakenda veita oft mismunandi stuðning við HTTP samskiptareglur, en um leið safna beiðnum frá mismunandi notendum inn í sameiginlega rás. Til að tengja móttökubeiðnirnar í framendanum og bakendavinnslubeiðnirnar, er komið á langvarandi TCP-tengingu, þar sem notendabeiðnir eru sendar, sendar eftir keðjunni hver á eftir annarri, aðskilin með HTTP-samskiptareglum. Til að aðskilja beiðnir eru hausarnir „Content-Length“ (ákvarðar heildarstærð gagna í beiðninni) og „
Vandamálið kemur upp ef framhliðin styður aðeins „Content-Length“ en hunsar „Transfer-Encoding: chunked“ (til dæmis gerði Akamai CDN þetta) eða öfugt. Ef Transfer-Encoding: chunked er studd á báðum hliðum, er hægt að nota útfærslueiginleika HTTP hausþátta fyrir árás (til dæmis þegar framendinn hunsar línur eins og "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked" ”, “Transfer-encoding” :[tab]chunked”, “X: X[\n]Transfer-encoding: chunked”, “Transfer-encoding[\n]: chunked” eða “Transfer-encoding: chunked”, og bakendinn vinnur úr þeim).
Í þessu tilviki getur árásarmaður sent beiðni sem inniheldur bæði "Content-Length" og "Transfer-Encoding: chunked" hausana, en stærðin í "Content-Length" samsvarar ekki stærð búta keðjunnar, sem er minna en raunverulegt gildi. Ef framendinn vinnur og framsendir beiðnina í samræmi við "Content-Length" og bakendinn bíður eftir að blokkinni ljúki byggt á "Transfer-Encoding: chunked", þá mun endir gagna sem byggjast á "Transfer-Encoding: chunked" vera ákvörðuð fyrr og það sem eftir er af beiðninni verður árásarmaðurinn í upphafi næstu beiðni, þ.e. árásarmaðurinn mun geta hengt handahófskennd gögn við upphaf beiðni einhvers annars sem send er næst.
Til að ákvarða vandamálið í notuðu framenda-bakenda samsetningunni geturðu sent beiðni eins og þessa í gegnum framenda:
POST /um HTTP/1.1
Gestgjafi: example.com
Flutningskóðun: klumpur
Innihaldslengd: 4
1
Z
Q
Vandamálið er til staðar ef bakendinn vinnur ekki strax úr beiðninni og bíður eftir komu endanlegrar núllmarkablokkar af gögnum. Fyrir fullkomnari skoðun
Að framkvæma raunverulega árás fer eftir getu vefsvæðisins sem ráðist er á, til dæmis, þegar þú ræðst á Trello vefforritið geturðu skipt út byrjun beiðninnar (skipta um gögn eins og „PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake“) og sendu skilaboð sem innihalda upprunalega beiðni þriðja aðila notanda og auðkenningarköku sem tilgreind er í henni. Fyrir árás á saas-app.com reyndist mögulegt að skipta út JavaScript kóða í svarinu með því að skipta honum út í einni af færibreytum beiðninnar. Fyrir árásina á redhat.com var innri meðferðaraðili notaður til að beina á vefsíðu árásarmannsins (beiðni á forminu „POST /search?dest=../assets/idx?redir=//[netvarið]/ HTTP/1.1").
Með því að nota aðferðina fyrir efnismiðlunarnet var hægt að einfaldlega skipta um umbeðna síðu með því að skipta út "Host:" hausnum. Árásina er einnig hægt að nota til að eitra fyrir innihaldi skyndiminniskerfa og vinna úr skyndiminni trúnaðargögnum. Hápunktur aðferðarinnar var skipulagning árásar á PayPal, sem gerði það mögulegt að stöðva lykilorð sem notendur sendu við auðkenningu (iframe beiðninni var breytt til að keyra JavaScript í samhengi við paypal.com/us/gifts síðuna, fyrir sem CSP (Content Security Policy) var ekki beitt).
Athyglisvert er að árið 2005 var það
Heimild: opennet.ru