PostMessage Vulnerabilities
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
PostMessage inatumia kazi ifuatayo kutuma ujumbe:
Note that targetOrigin inaweza kuwa '*' au URL kama https://company.com. Katika hali ya pili, ujumbe unaweza kutumwa tu kwa ile domain (hata kama asili ya kitu cha dirisha ni tofauti). Ikiwa wildcard inatumika, ujumbe unaweza kutumwa kwa domain yoyote, na utatumwa kwa asili ya kitu cha Dirisha.
Kama ilivyoelezwa katika ripoti hii ikiwa unapata ukurasa ambao unaweza iframed (hakuna ulinzi wa X-Frame-Header) na ambao unatumia ujumbe wa nyeti kupitia postMessage kwa kutumia wildcard (*), unaweza kubadilisha asili ya iframe na leak ujumbe wa nyeti kwa domain inayodhibitiwa na wewe.
Kumbuka kwamba ikiwa ukurasa unaweza kuiframed lakini targetOrigin imewekwa kwa URL na sio kwa wildcard, hila hii haitafanya kazi.
addEventListener ni kazi inayotumiwa na JS kutangaza kazi ambayo inatarajia postMessages.
Kodi kama ifuatavyo itatumika:
Note katika kesi hii jinsi kitu cha kwanza ambacho msimbo unafanya ni kuangalia asili. Hii ni muhimu sana hasa ikiwa ukurasa utafanya kitu chochote nyeti na taarifa iliyopokelewa (kama kubadilisha nywila). Ikiwa haikangalii asili, washambuliaji wanaweza kuwafanya waathirika kutuma data isiyo na mipaka kwa hizi endpoints na kubadilisha nywila za waathirika (katika mfano huu).
Ili kupata wasikilizaji wa matukio katika ukurasa wa sasa unaweza:
Tafuta msimbo wa JS kwa window.addEventListener na $(window).on (toleo la JQuery)
Tekeleza katika console ya zana za maendeleo: getEventListeners(window)
Nenda kwa Elements --> Event Listeners katika zana za maendeleo za kivinjari
Tumia nyongeza ya kivinjari kama https://github.com/benso-io/posta au https://github.com/fransr/postMessage-tracker. Hizi nyongeza za kivinjari zitachukua ujumbe wote na kuonyesha kwako.
event.isTrusted sifa inachukuliwa kuwa salama kwani inarudisha True tu kwa matukio ambayo yanatokana na vitendo halisi vya mtumiaji. Ingawa ni vigumu kupita ikiwa imewekwa vizuri, umuhimu wake katika ukaguzi wa usalama ni wa kutia maanani.
Matumizi ya indexOf() kwa uthibitishaji wa asili katika matukio ya PostMessage yanaweza kuwa na uwezekano wa kupita. Mfano unaoonyesha udhaifu huu ni:
Njia ya search() kutoka String.prototype.search() inakusudia kwa matumizi ya kawaida, si nyuzi. Kupitisha chochote kisichokuwa regexp kunasababisha uhamasishaji wa kimya kwa regex, na kufanya njia hiyo kuwa hatarishi. Hii ni kwa sababu katika regex, nukta (.) inafanya kazi kama wildcard, ikiruhusu kupita uthibitishaji na maeneo yaliyoundwa kwa njia maalum. Kwa mfano:
Kazi ya match(), kama search(), inashughulikia regex. Ikiwa regex imejengwa vibaya, inaweza kuwa na uwezekano wa kupita.
Kazi ya escapeHtml inakusudia kusafisha ingizo kwa kukwepa wahusika. Hata hivyo, haizalishi kitu kipya kilichokwepwa bali inabadilisha mali za kitu kilichopo. Tabia hii inaweza kutumika. Haswa, ikiwa kitu kinaweza kubadilishwa kwa namna ambayo mali yake inayodhibitiwa haikubali hasOwnProperty, escapeHtml haitafanya kazi kama inavyotarajiwa. Hii inaonyeshwa katika mifano hapa chini:
Kushindwa Kutarajiwa:
Kupita kukwepa:
Katika muktadha wa udhaifu huu, kitu cha File kinapatikana kwa urahisi kutokana na sifa yake ya kusoma tu name. Sifa hii, inapokuwa katika templeti, haijasafishwa na kazi ya escapeHtml, ikisababisha hatari za usalama.
Sifa ya document.domain katika JavaScript inaweza kuwekwa na skripti ili kupunguza eneo, ikiruhusu utekelezaji wa sera ya asili sawa kuwa rahisi zaidi ndani ya eneo moja la mzazi.
Wakati wa kuingiza ukurasa wa wavuti ndani ya sandboxed iframe kwa kutumia %%%%%%, ni muhimu kuelewa kwamba asili ya iframe itakuwa imewekwa kuwa null. Hii ni muhimu hasa wakati wa kushughulikia sifa za sandbox na athari zao kwenye usalama na utendaji.
Kwa kubainisha allow-popups katika sifa ya sandbox, dirisha lolote la popup lililofunguliwa kutoka ndani ya iframe linapata vizuizi vya sandbox vya mzazi wake. Hii inamaanisha kwamba isipokuwa sifa ya allow-popups-to-escape-sandbox pia imejumuishwa, asili ya dirisha la popup pia imewekwa kuwa null, ikilingana na asili ya iframe.
Kwa hivyo, wakati popup inafunguliwa chini ya hali hizi na ujumbe unatumwa kutoka iframe hadi popup kwa kutumia postMessage, pande zote za kutuma na kupokea zina asili zao zimewekwa kuwa null. Hali hii inasababisha hali ambapo e.origin == window.origin inathibitishwa kuwa kweli (null == null), kwa sababu iframe na popup zinashiriki thamani sawa ya asili ya null.
Kwa maelezo zaidi soma:
Bypassing SOP with Iframes - 1Inawezekana kuangalia ikiwa ujumbe ulitoka kwenye dirisha sawa ambalo skripti inasikiliza (hasa ya kuvutia kwa Content Scripts kutoka nyongeza za kivinjari kuangalia ikiwa ujumbe ulitumwa kutoka kwenye ukurasa sawa):
You can force e.source of a message to be null by creating an iframe that sends the postMessage and is immediately deleted.
For more information read:
Bypassing SOP with Iframes - 2Ili kutekeleza mashambulizi haya, kwa njia bora utakuwa na uwezo wa kueka ukurasa wa mtandaoni wa mwathirika ndani ya iframe. Lakini vichwa vingine kama X-Frame-Header vinaweza kuzuia hiyo tabia.
Katika hali hizo, bado unaweza kutumia shambulizi ambalo halijafichwa sana. Unaweza kufungua kichupo kipya kwa programu ya wavuti iliyo hatarini na kuwasiliana nayo:
Katika ukurasa ufuatao unaweza kuona jinsi unavyoweza kuiba data nyeti za postmessage zilizotumwa kwa iframe ya mtoto kwa kuzuia ukurasa mkuu kabla ya kutuma data na kutumia XSS katika mtoto ili kuvuja data kabla haijapokelewa:
Blocking main page to steal postmessageIkiwa unaweza iframe ukurasa wa wavuti bila X-Frame-Header ambao una iframe nyingine, unaweza kubadilisha eneo la iframe hiyo ya mtoto, hivyo ikiwa inapata postmessage iliyotumwa kwa kutumia wildcard, mshambuliaji anaweza kubadilisha asilimia ya iframe hiyo kuwa ukurasa unaodhibitiwa na yeye na kuiba ujumbe:
Steal postmessage modifying iframe locationKatika hali ambapo data iliyotumwa kupitia postMessage inatekelezwa na JS, unaweza iframe ukurasa na kutumia uchafuzi wa prototype/XSS ukituma exploit kupitia postMessage.
Mfano kadhaa wa XSS nzuri sana zilizofafanuliwa kupitia postMessage zinaweza kupatikana katika https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html
Mfano wa exploit ya kutumia Uchafuzi wa Prototype na kisha XSS kupitia postMessage kwa iframe:
Kwa maelezo zaidi:
Kiungo cha ukurasa kuhusu prototype pollution
Kiungo cha ukurasa kuhusu XSS
Kiungo cha ukurasa kuhusu client side prototype pollution to XSS
Kufanya mazoezi: https://github.com/yavolo/eventlistener-xss-recon
Jifunze & fanya mazoezi ya AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Jifunze & fanya mazoezi ya GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
