Mashambulizi dhidi ya mifumo ya mbele-nyuma-nyuma ambayo huturuhusu kujikita katika maombi ya watu wengine

Imefichuliwa maelezo ya shambulio jipya kwenye tovuti zinazotumia modeli ya-mbele-nyuma-nyuma, kama vile zile zinazoendeshwa kupitia mitandao ya uwasilishaji wa maudhui, visawazishaji vya upakiaji au proksi. Shambulio hilo huruhusu, kwa kutuma maombi fulani, kuweka kabari katika maudhui ya maombi mengine yanayochakatwa katika uzi ule ule kati ya sehemu ya mbele na ya nyuma. Njia iliyopendekezwa ilitumiwa kwa mafanikio kupanga shambulio ambalo lilifanya iwezekane kukamata vigezo vya uthibitishaji wa watumiaji wa huduma ya PayPal, ambayo ililipa watafiti takriban dola elfu 40 kama sehemu ya mpango wa kufahamisha juu ya uwepo wa udhaifu ambao haujashughulikiwa. Shambulio hilo pia linatumika kwa tovuti zinazotumia mtandao wa uwasilishaji wa maudhui ya Akamai.

Kiini cha tatizo ni kwamba sehemu za mbele na za nyuma mara nyingi hutoa viwango tofauti vya usaidizi kwa itifaki ya HTTP, lakini wakati huo huo hujumuisha maombi kutoka kwa watumiaji tofauti kwenye kituo cha kawaida. Ili kuunganisha maombi ya kupokea mbele na maombi ya usindikaji wa nyuma, uunganisho wa muda mrefu wa TCP umeanzishwa, kwa njia ambayo maombi ya mtumiaji hupitishwa, hupitishwa kando ya mlolongo mmoja baada ya mwingine, ikitenganishwa kwa njia ya itifaki ya HTTP. Ili kutenganisha maombi, vichwa "Urefu wa Maudhui" (huamua saizi ya jumla ya data katika ombi) na "Uhamishaji-Usimbaji: umekatwa vipande vipande"(inakuruhusu kuhamisha data katika sehemu, kubainisha vizuizi vya ukubwa tofauti katika umbizo "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0").

Tatizo hutokea ikiwa sehemu ya mbele inaauni tu "Urefu-Maudhui" lakini inapuuza "Usimbaji-Hamisha: iliyokatwa" (kwa mfano, Akamai CDN ilifanya hivi) au kinyume chake. Ikiwa Usimbaji-Hamisha: chunked inatumika kwa pande zote mbili, vipengele vya utekelezaji vya vichanganuzi vya vichwa vya HTTP vinaweza kutumika kwa shambulio (kwa mfano, sehemu ya mbele inapopuuza mistari kama vile "Transfer-Encoding: xchunked", "Transfer-Encoding: chunked ”, “Usimbaji wa Uhawilishaji” :[tab]iliyokatwa vipande vipande", "X: X[\n]Usimbaji-Hamisha: umekatwa", "Usimbaji wa Uhawilishaji[\n]: umekatwa vipande vipande" au "Usimbaji-Hamisha : umekatwa", na backend imefanikiwa kuzichakata).

Katika hali hii, mshambulizi anaweza kutuma ombi ambalo lina vichwa vya "Urefu-Maudhui" na "Uhamishaji-Usimbaji: vipande vipande", lakini ukubwa katika "Urefu-Maudhui" haulingani na saizi ya mnyororo uliokatwa vipande vipande. ni ndogo kuliko thamani halisi. Ikiwa sehemu ya mbele itachakata na kupeleka ombi kulingana na "Urefu wa Yaliyomo" na sehemu ya nyuma inangojea kizuizi kukamilika kwa msingi wa "Uhamishaji-Usimbaji: uliopunguzwa", basi mwisho wa data kulingana na "Usimbaji-Uhamishaji: iliyokatwa" itakuwa. kuamua mapema na mkia uliobaki wa ombi mshambuliaji atakuwa mwanzoni mwa ombi linalofuata, i.e. mshambulizi ataweza kuambatisha data kiholela kwa mwanzo wa ombi la mtu mwingine kutumwa ijayo.

Mashambulizi dhidi ya mifumo ya mbele-nyuma-nyuma ambayo huturuhusu kujikita katika maombi ya watu wengine

Ili kubaini tatizo katika mseto wa mandhari ya mbele uliotumika, unaweza kutuma ombi kama hili kupitia sehemu ya mbele:

POST /kuhusu HTTP/1.1
Mwenyeji: example.com
Uhamishaji-Usimbaji: umekatwa vipande vipande
Urefu wa yaliyomo: 4

1
Z
Q

Shida iko ikiwa sehemu ya nyuma haitashughulikia ombi mara moja na inangojea kuwasili kwa kizuizi cha mwisho cha sifuri cha data iliyokatwa. Kwa ukaguzi kamili zaidi tayari matumizi maalum ambayo pia hujaribu mbinu zinazowezekana za kuficha kichwa cha "Uhamishaji-Usimbaji: kilichokatwa" kutoka upande wa mbele.

Kufanya shambulio la kweli kunategemea uwezo wa tovuti iliyoshambuliwa, kwa mfano, unaposhambulia programu ya wavuti ya Trello, unaweza kuchukua nafasi ya mwanzo wa ombi (data mbadala kama vile “PUT /1/members/1234... x=x&csrf =1234&username=testzzz&bio=cake”) na utume ujumbe ikijumuisha ombi asili la mtumiaji mwingine na Kidakuzi cha uthibitishaji kilichobainishwa ndani yake. Kwa shambulio la saas-app.com, iliwezekana kubadilisha msimbo wa JavaScript katika jibu kwa kuuweka katika mojawapo ya vigezo vya ombi. Kwa shambulio la redhat.com, kidhibiti cha ndani kilitumiwa kuelekeza kwenye tovuti ya mshambulizi (ombi la fomu ya “POST /search?dest=../assets/idx?redir=//[barua pepe inalindwa]/ HTTP/1.1").

Kutumia mbinu ya mitandao ya uwasilishaji maudhui kulifanya iwezekane kuchukua nafasi ya tovuti iliyoombwa kwa kubadilisha kichwa cha "Mpangishi:". Shambulio hilo pia linaweza kutumika kutia sumu yaliyomo kwenye mifumo ya akiba ya maudhui na kutoa data ya siri iliyohifadhiwa. Kilele cha mbinu hiyo kilikuwa upangaji wa shambulio kwenye PayPal, ambayo ilifanya iwezekane kunasa manenosiri yaliyotumwa na watumiaji wakati wa uthibitishaji (ombi la iframe lilirekebishwa ili kutekeleza JavaScript katika muktadha wa ukurasa wa paypal.com/us/gifts, kwa ambayo CSP (Sera ya Usalama ya Maudhui) haikutumika).

Inafurahisha, mnamo 2005 kulikuwa na iliyopendekezwa mbinu sawa ya kudanganya ambayo hukuruhusu kuharibu data katika seva mbadala za akiba (Tomcat, ngisi, mod_proxy) au kukwepa uzuiaji wa ngome kwa kubainisha maombi kadhaa ya "GET" au "POST" ndani ya kipindi kimoja cha HTTP.

Chanzo: opennet.ru

Kuongeza maoni