besonderhede van 'n nuwe aanval op werwe wat 'n front-end-back-end-model gebruik, soos dié wat deur inhoudafleweringsnetwerke, lasbalanseerders of gevolmagtigdes loop. Die aanval laat toe om, deur sekere versoeke te stuur, in te wig in die inhoud van ander versoeke wat in dieselfde draad tussen die voorkant en agterkant verwerk word. Die voorgestelde metode is suksesvol gebruik om 'n aanval te organiseer wat dit moontlik gemaak het om die verifikasieparameters van gebruikers van die PayPal-diens te onderskep, wat navorsers ongeveer 40 duisend dollar betaal het as deel van 'n program om in te lig oor die teenwoordigheid van onopgeloste kwesbaarhede. Die aanval is ook van toepassing op werwe wat die Akamai-inhoudafleweringsnetwerk gebruik.
Die kern van die probleem is dat frontends en backends dikwels verskillende vlakke van ondersteuning vir die HTTP-protokol bied, maar terselfdertyd versoeke van verskillende gebruikers in 'n gemeenskaplike kanaal inkapsel. Om die frontend-ontvangsversoeke en die backend-verwerkingsversoeke te verbind, word 'n langlewende TCP-verbinding tot stand gebring, waardeur gebruikerversoeke versend, langs die ketting een na die ander versend word, geskei deur middel van die HTTP-protokol. Om versoeke te skei, die opskrifte "Content-Length" (bepaal die totale grootte van die data in die versoek) en ""(laat jou toe om data in dele oor te dra, en spesifiseer blokke van verskillende groottes in die formaat "{grootte}\r\n{blok}\r\n{grootte}\r\n{blok}\r\n0").
Die probleem ontstaan as die frontend slegs “Content-Length” ondersteun, maar “Transfer-Encoding: chunked” ignoreer (byvoorbeeld, Akamai CDN het dit gedoen) of andersom. As Transfer-Encoding: chunked aan beide kante ondersteun word, kan die implementeringskenmerke van HTTP-kopontleders vir 'n aanval gebruik word (byvoorbeeld, wanneer die voorkant reëls soos "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked" ignoreer ”, “Transfer-Encoding” :[tab]chunked”, "X: X[\n]Transfer-Encoding: chunked", "Transfer-Encoding[\n]: chunked" of "Transfer-Encoding : chunked", en die agterkant verwerk dit suksesvol).
In hierdie geval kan 'n aanvaller 'n versoek stuur wat beide die "Content-Length" en "Transfer-Encoding: chunked"-opskrifte bevat, maar die grootte in "Content-Length" stem nie ooreen met die grootte van die chunked-ketting nie, wat is kleiner as die werklike waarde. As die frontend die versoek verwerk en aanstuur volgens "Content-Length" en die backend wag vir die blok om te voltooi gebaseer op "Transfer-Encoding: chunked", dan sal die einde van die data gebaseer op "Transfer-Encoding: chunked" vroeër bepaal word en die oorblywende stert van die versoek sal die aanvaller aan die begin van die volgende versoek wees, m.a.w. die aanvaller sal arbitrêre data kan heg aan die begin van iemand anders se versoek wat volgende versend word.
Om die probleem in die gebruikte frontend-backend-kombinasie te bepaal, kan u 'n versoek soos hierdie via die frontend stuur:
POST /oor HTTP/1.1
Gasheer: example.com
Oordrag-enkodering: stukke
Inhoud-Lengte: 4
1
Z
Q
Die probleem is teenwoordig as die backend nie onmiddellik die versoek verwerk nie en wag vir die aankoms van die finale nul-begrensende blok van stukkies data. Vir 'n meer volledige tjek 'n spesiale hulpprogram wat ook moontlike metodes toets om die "Transfer-Encoding: chunked"-kopskrif vanaf die voorkant te verberg.
Om 'n werklike aanval uit te voer hang af van die vermoëns van die aangeval werf, byvoorbeeld, wanneer jy die Trello-webtoepassing aanval, kan jy die begin van die versoek vervang (vervang data soos "PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) en stuur 'n boodskap wat die oorspronklike versoek van 'n derdeparty-gebruiker en die verifikasiekoekie daarin gespesifiseer bevat. Vir 'n aanval op saas-app.com, blyk dit moontlik te wees om JavaScript-kode in die antwoord te vervang deur dit in een van die versoekparameters te vervang. Vir die aanval op redhat.com is 'n interne hanteerder gebruik om na die aanvaller se webwerf te herlei ('n versoek van die vorm "POST /search?dest=../assets/idx?redir=//[e-pos beskerm]/ HTTP/1.1").
Die gebruik van die metode vir inhoudafleweringsnetwerke het dit moontlik gemaak om die gevraagde webwerf eenvoudig te vervang deur die "Host:"-opskrif te vervang. Die aanval kan ook gebruik word om die inhoud van inhoudkasstelsels te vergiftig en vertroulike data te onttrek. Die toppunt van die metode was die organisasie van 'n aanval op PayPal, wat dit moontlik gemaak het om wagwoorde wat deur gebruikers gestuur is tydens stawing te onderskep (die iframe-versoek is gewysig om JavaScript in die konteks van die paypal.com/us/gifts-bladsy uit te voer, vir watter CSP (Content Security Policy) nie toegepas is nie).
Interessant genoeg was daar in 2005 'n wesenlik soortgelyke versoek-spoofing-tegniek wat jou toelaat om data in caching-gevolmagtigdes (Tomcat, squid, mod_proxy) te bedrieg of firewall-blokkering te omseil deur verskeie "GET" of "POST"-versoeke binne een HTTP-sessie te spesifiseer.
Bron: opennet.ru