details fan in nije oanfal op siden dy't in front-end-back-end-model brûke, lykas dyjingen dy't rinne troch netwurken foar levering fan ynhâld, loadbalancers of proxy's. De oanfal lit, troch it ferstjoeren fan bepaalde oanfragen, yn 'e ynhâld fan oare oanfragen ferwurke wurde yn deselde thread tusken de frontend en efterkant. De foarstelde metoade waard mei súkses brûkt om in oanfal te organisearjen dy't it mooglik makke om de autentikaasjeparameters fan brûkers fan 'e PayPal-tsjinst te ûnderskeppen, dy't ûndersikers sa'n 40 tûzen dollar betelle as ûnderdiel fan in programma om te ynformearjen oer de oanwêzigens fan unpatched kwetsberens. De oanfal is ek fan tapassing op siden dy't it Akamai-ynhâldnetwurk brûke.
De crux fan it probleem is dat frontends en backends faak ferskate nivo's fan stipe foar it HTTP-protokol leverje, mar tagelyk fersiken fan ferskate brûkers yn in mienskiplik kanaal ynkapselje. Om de frontend-ûntfangende oanfragen te ferbinen en de fersiken foar ferwurkjen fan 'e backend, wurdt in lange libbene TCP-ferbining fêststeld, wêrmei brûkersoanfragen wurde ferstjoerd, de iene nei de oare oer de keatling oerbrocht, skieden troch it HTTP-protokol. Om fersiken te skieden, de kopteksten "Ynhâld-Length" (bepaalt de totale grutte fan de gegevens yn it fersyk) en ""(meit jo gegevens yn dielen oerdrage, blokken fan ferskate grutte oantsjutte yn it formaat "{grutte}\r\n{blok}\r\n{grutte}\r\n{blok}\r\n0").
It probleem ûntstiet as de frontend allinich "Ynhâld-Length" stipet, mar "Transfer-Encoding: chunked" negeart (bygelyks Akamai CDN die dit) of oarsom. As Transfer-Encoding: chunked oan beide kanten wurdt stipe, kinne de ymplemintaasjefunksjes fan HTTP-header-parsers brûkt wurde foar in oanfal (bygelyks as de foarkant rigels negeart lykas "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked" ”, “Transfer-Encoding” :[tab]chunked”, "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" of "Overdracht-kodearring: chunked", en de backend ferwurket se mei súkses).
Yn dit gefal kin in oanfaller in fersyk stjoere dy't sawol de "Content-Length" as "Transfer-Encoding: chunked" kopteksten befettet, mar de grutte yn "Content-Length" komt net oerien mei de grutte fan 'e chunked chain, wat is lytser as de werklike wearde. As de frontend it fersyk ferwurket en trochstjoert neffens "Ynhâld-Length" en de efterkant wachtet op it blok om te foltôgjen basearre op "Transfer-Encoding: chunked", dan sil it ein fan 'e gegevens basearre op "Transfer-Encoding: chunked" wurde bepaald earder en de oerbleaune sturt fan it fersyk de oanfaller sil wêze oan it begjin fan de folgjende fersyk, i.e. de oanfaller sil by steat wêze om te heakjen willekeurige gegevens oan it begjin fan in oar syn fersyk neist oerdroegen.
Om it probleem te bepalen yn 'e brûkte frontend-backend-kombinaasje, kinne jo in fersyk lykas dit stjoere fia de frontend:
POST /oer HTTP/1.1
Host: example.com
Oerdracht-kodearring: chunked
Ynhâldslange: 4
1
Z
Q
It probleem is oanwêzich as de backend it fersyk net daliks ferwurket en wachtet op de komst fan it definitive nul-beheinende blok fan stikkene gegevens. Foar in mear folsleine kontrôle in spesjaal hulpprogramma dat ek mooglike metoaden testet foar it ferbergjen fan de koptekst "Transfer-Encoding: chunked" fan 'e frontend.
It útfieren fan in echte oanfal hinget ôf fan 'e mooglikheden fan' e oanfalle side, bygelyks by it oanfallen fan 'e Trello-webapplikaasje kinne jo it begjin fan it fersyk ferfange (ferfange gegevens lykas "PUT /1/members/1234... x=x&csrf =1234&brûkersnamme=testzzz&bio=cake”) en stjoer in berjocht mei it orizjinele fersyk fan in brûker fan tredden en it dêryn spesifisearre autentikaasjekoekje. Foar in oanfal op saas-app.com die bliken dat it mooglik wie om JavaScript-koade te ferfangen yn it antwurd troch it te ferfangen yn ien fan 'e fersykparameters. Foar de oanfal op redhat.com waard in ynterne handler brûkt om troch te lieden nei de webside fan 'e oanfaller (in fersyk fan it formulier "POST /search?dest=../assets/idx?redir=//[e-post beskerme]/ HTTP/1.1").
It brûken fan de metoade foar netwurken foar levering fan ynhâld makke it mooglik om de oanfrege side gewoan te ferfangen troch de koptekst "Host:" te ferfangen. De oanfal kin ek brûkt wurde om de ynhâld fan ynhâld-caching-systemen te fergiftigjen en cached fertroulike gegevens te ekstrahearjen. It hichtepunt fan 'e metoade wie de organisaasje fan in oanfal op PayPal, dy't it mooglik makke om wachtwurden te ûnderskeppen dy't troch brûkers stjoerd binne tidens de autentikaasje (it iframe-fersyk waard oanpast om JavaSkript út te fieren yn' e kontekst fan 'e side paypal.com/us/gifts, foar hokker CSP (Content Security Policy) net tapast waard).
Nijsgjirrich is dat der yn 2005 wie in essinsjeel ferlykbere spoofing-technyk foar fersyk wêrmei jo gegevens kinne spoofje yn caching-proxies (Tomcat, squid, mod_proxy) of firewall-blokkering omgean troch ferskate "GET" of "POST" oanfragen binnen ien HTTP-sesje op te jaan.
Boarne: opennet.ru