Një sulm ndaj sistemeve front-end-back-end që na lejon të futemi në kërkesat e palëve të treta

Zbuluar detajet e një sulmi të ri në sajtet që përdorin një model front-end-back-end, të tilla si ato që kalojnë përmes rrjeteve të ofrimit të përmbajtjes, balancuesve të ngarkesës ose proxies. Sulmi lejon, duke dërguar kërkesa të caktuara, të futet në përmbajtjen e kërkesave të tjera të përpunuara në të njëjtën fillesë midis frontendit dhe backend-it. Metoda e propozuar u përdor me sukses për të organizuar një sulm që bëri të mundur përgjimin e parametrave të vërtetimit të përdoruesve të shërbimit PayPal, i cili u paguan studiuesve rreth 40 mijë dollarë si pjesë e një programi për të informuar për praninë e dobësive të papatchuara. Sulmi është gjithashtu i zbatueshëm për faqet që përdorin rrjetin e shpërndarjes së përmbajtjes Akamai.

Thelbi i problemit është se frontends dhe backends shpesh ofrojnë nivele të ndryshme të mbështetjes për protokollin HTTP, por në të njëjtën kohë përmbledhin kërkesat nga përdorues të ndryshëm në një kanal të përbashkët. Për të lidhur kërkesat e pranimit të frontendit dhe kërkesat e përpunimit të backend-it, krijohet një lidhje TCP jetëgjatë, përmes së cilës transmetohen kërkesat e përdoruesve, të transmetuara përgjatë zinxhirit njëra pas tjetrës, të ndara me anë të protokollit HTTP. Për të ndarë kërkesat, titujt "Gjatësia e përmbajtjes" (përcakton madhësinë totale të të dhënave në kërkesë) dhe "Transferimi-Enkodimi: i copëtuar"(ju lejon të transferoni të dhëna në pjesë, duke specifikuar blloqe me madhësi të ndryshme në formatin "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").

Problemi lind nëse frontend mbështet vetëm "Content-Length" por injoron "Transfer-Encoding: chunked" (për shembull, Akamai CDN e bëri këtë) ose anasjelltas. Nëse Transfer-Encoding: chunked mbështetet në të dyja anët, veçoritë e zbatimit të analizuesve të kokës HTTP mund të përdoren për një sulm (për shembull, kur pjesa e përparme shpërfill linjat si "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked ", "Transfer-Encoding" :[tab]coding", "X: X[\n]Transfer-Encoding: conked", "Transfer-Encoding[\n]: conked" ose "Transfer-Encoding : conked", dhe backend-i i përpunon me sukses).

Në këtë rast, një sulmues mund të dërgojë një kërkesë që përmban si titullin "Content-Length" dhe "Transfer-Encoding: chunked", por madhësia në "Content-Length" nuk korrespondon me madhësinë e zinxhirit të copëtuar, i cili është më e vogël se vlera aktuale. Nëse pjesa e përparme përpunon dhe përcjell kërkesën sipas "Gjatësia e Përmbajtjes" dhe mbështetja pret që blloku të përfundojë bazuar në "Transfer-Encoding: chunked", atëherë fundi i të dhënave të bazuara në "Transfer-Encoding: chunked" do të të përcaktohet më herët dhe bishti i mbetur i kërkesës sulmuesi do të jetë në fillim të kërkesës së ardhshme, d.m.th. sulmuesi do të jetë në gjendje të bashkëngjisë të dhëna arbitrare në fillim të kërkesës së dikujt tjetër të transmetuar më pas.

Për të përcaktuar problemin në kombinimin e përdorur frontend-backend, mund të dërgoni një kërkesë si kjo nëpërmjet frontend-it:

POST /rreth HTTP/1.1
Pritësi: shembull.com
Transferimi-Enkodimi: i copëtuar
Gjatësia e përmbajtjes: 4

1
Z
Q

Problemi është i pranishëm nëse backend-i nuk e përpunon menjëherë kërkesën dhe pret mbërritjen e bllokut përfundimtar zero kufizues të të dhënave të copëtuara. Për një kontroll më të plotë përgatitur një mjet i veçantë që teston gjithashtu metodat e mundshme për fshehjen e titullit "Transfer-Encoding: chunked" nga pjesa e përparme.

Kryerja e një sulmi të vërtetë varet nga aftësitë e faqes së sulmuar, për shembull, kur sulmoni aplikacionin ueb Trello, mund të zëvendësoni fillimin e kërkesës (zëvendësoni të dhënat si "PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) dhe dërgoni një mesazh duke përfshirë kërkesën origjinale të një përdoruesi të palës së tretë dhe Cookie-n e vërtetimit të specifikuar në të. Për një sulm në saas-app.com, doli të ishte e mundur të zëvendësohej kodi JavaScript në përgjigje duke e zëvendësuar atë në një nga parametrat e kërkesës. Për sulmin në redhat.com, një mbajtës i brendshëm u përdor për të ridrejtuar në faqen e internetit të sulmuesit (një kërkesë e formularit "POST /search?dest=../assets/idx?redir=//[email mbrojtur]/ HTTP/1.1").

Përdorimi i metodës për rrjetet e shpërndarjes së përmbajtjes bëri të mundur thjesht zëvendësimin e faqes së kërkuar duke zëvendësuar kokën "Host:". Sulmi mund të përdoret gjithashtu për të helmuar përmbajtjen e sistemeve të ruajtjes së përmbajtjes dhe për të nxjerrë të dhëna konfidenciale të ruajtura në memorie. Kulmi i metodës ishte organizimi i një sulmi në PayPal, i cili bëri të mundur përgjimin e fjalëkalimeve të dërguara nga përdoruesit gjatë vërtetimit (kërkesa iframe u modifikua për të ekzekutuar JavaScript në kontekstin e faqes paypal.com/us/gifts, për e cila CSP (Politika e Sigurisë së Përmbajtjes) nuk u zbatua).

Interesante, në vitin 2005 ka pasur propozuar një teknikë në thelb e ngjashme e mashtrimit të kërkesave që ju lejon të mashtroni të dhënat në proxies në memorie (Tomcat, squid, mod_proxy) ose të anashkaloni bllokimin e murit të zjarrit duke specifikuar disa kërkesa "GET" ose "POST" brenda një sesioni HTTP.

Burimi: opennet.ru