PostMessage Vulnerabilities
Madokezo ya PostMessage
WhiteIntel ni injini ya utaftaji inayotumia dark-web ambayo inatoa huduma za bure kuchunguza ikiwa kampuni au wateja wake wame vamiwa na malware za kuiba.
Lengo kuu la WhiteIntel ni kupambana na utekaji wa akaunti na mashambulio ya ransomware yanayotokana na programu hasidi za kuiba taarifa.
Unaweza kutembelea tovuti yao na kujaribu injini yao bure kwa:
Tuma PostMessage
PostMessage hutumia kazi ifuatayo kutuma ujumbe:
Tafadhali kumbuka kwamba targetOrigin inaweza kuwa '*' au URL kama https://company.com. Katika skenario ya pili, ujumbe unaweza kutumwa tu kwa kikoa hicho (hata kama asili ya kitu cha dirisha ni tofauti). Ikiwa alama ya joker inatumika, ujumbe unaweza kutumwa kwa kikoa chochote, na utatumwa kwa asili ya kitu cha Dirisha.
Kuvamia iframe & alama ya joker katika targetOrigin
Kama ilivyoelezwa katika ripoti hii ikiwa utapata ukurasa ambao unaweza kuingizwa kwa iframe (bila ulinzi wa X-Frame-Header
) na ambao unatuma ujumbe wa hisia kupitia postMessage ukitumia alama ya joker (*), unaweza kubadilisha asili ya iframe na kuvuja ujumbe wa hisia kwenda kwa kikoa kinachodhibitiwa na wewe.
Tafadhali kumbuka kwamba ikiwa ukurasa unaweza kuingizwa kwa iframe lakini targetOrigin imewekwa kwa URL na sio kwa alama ya joker, hila hii haitafanya kazi.
Utekaji wa addEventListener
addEventListener
ndio kazi hutumiwa na JS kutangaza kazi ambayo inatarajia postMessages
.
Msimbo kama ule wa kufuatia utatumika:
Tafadhali kumbuka jinsi jambo la kwanza ambalo msimbo unafanya ni kuangalia asili. Hii ni muhimu sana hasa ikiwa ukurasa utafanya kitu cha hisia na habari iliyopokelewa (kama kubadilisha nenosiri). Ikiwa haitoiangalia asili, wachomaji wanaweza kufanya waathiriwa watume data ya kupotosha kwa hii maeneo na kubadilisha nywila za waathiriwa (katika mfano huu).
Uchambuzi
Kwa lengo la kupata wasikilizaji wa tukio kwenye ukurasa wa sasa unaweza:
Tafuta msimbo wa JS kwa
window.addEventListener
na$(window).on
(toleo la JQuery)Tekeleza kwenye konsoli ya zana ya developer:
getEventListeners(window)
Nenda Elements --> Wasikilizaji wa Tukio katika zana za developer ya kivinjari
Tumia kifaa cha kivinjari kama https://github.com/benso-io/posta au https://github.com/fransr/postMessage-tracker. Vifaa hivi vya kivinjari vitakapo kukamata ujumbe wote na kuwaonyesha.
Pita kuthibitisha asili
Sifa ya
event.isTrusted
inachukuliwa kuwa salama kwani inarudishaTrue
tu kwa matukio yaliyozalishwa na vitendo halisi vya mtumiaji. Ingawa ni changamoto kuihepa ikiwa imefanywa kwa usahihi, umuhimu wake katika ukaguzi wa usalama ni muhimu.Matumizi ya
indexOf()
kwa uthibitisho wa asili katika matukio ya PostMessage yanaweza kuwa rahisi kwa kuihepa. Mfano unaoonyesha udhaifu huu ni:
Mbinu ya
search()
kutokaString.prototype.search()
inalenga kwenye mizani za kawaida, sio herufi. Kupitisha kitu kingine isipokuwa mizani kunapelekea uongofu wa lazima kuwa mizani, hivyo kufanya mbinu kuwa na hatari. Hii ni kwa sababu kwenye mizani, kipande (.) hufanya kama kichwa, kuruhusu kuihepa uthibitisho na uwanja ulioandaliwa kwa makini. Kwa mfano:
Kazi ya
match()
, kamasearch()
, inashughulikia mizani. Ikiwa mizani imeandaliwa vibaya, inaweza kuwa rahisi kuihepa.Kazi ya
escapeHtml
inalenga kusafisha vipande kwa kutoroka herufi. Hata hivyo, haifanyi kitu kipya kilichotoroka bali inabadilisha mali za kitu kilichopo. Tabia hii inaweza kutumiwa vibaya. Hasa, ikiwa kitu kinaweza kubadilishwa ili mali yake iliyodhibitiwa isikubalihasOwnProperty
,escapeHtml
haitafanya kama ilivyotarajiwa. Hii inaonyeshwa katika mifano hapa chini:Kukosekana kwa Matarajio:
Kuihepa kwa kutoroka:
Katika muktadha wa udhaifu huu, kitu cha File
kinafaa kutumiwa kwa sababu ya mali yake ya kusoma tu ya jina
. Mali hii, ikipotumiwa katika templeti, haifanyi safi na kazi ya escapeHtml
, ikiongoza kwa hatari za usalama.
Mali ya
document.domain
katika JavaScript inaweza kuwekwa na skripti ili kupunguza uwanja, kuruhusu utekelezaji wa sera ya asili sawa ndani ya uwanja wa mzazi mmoja.
Pita ya e.origin == window.origin
e.origin == window.origin
Wakati wa kuingiza ukurasa wa wavuti ndani ya iframe iliyofungwa kwa kutumia %%%%%%, ni muhimu kuelewa kuwa asili ya iframe itawekwa kwa null. Hii ni muhimu hasa unaposhughulika na vipengele vya sanduku na matokeo yake kwa usalama na utendaji.
Kwa kufafanua ruhusu-popups
katika kipengele cha sanduku, dirisha lolote la popup lililo funguliwa kutoka ndani ya iframe linarithi vikwazo vya sanduku vya mzazi wake. Hii inamaanisha kwamba isipokuwa kipengele cha ruhusu-popups-to-escape-sandbox
pia kimejumuishwa, asili ya dirisha la popup pia inawekwa kwa null
, ikilinganisha na asili ya iframe.
Kufuatia hivyo, wakati popup inapofunguliwa chini ya hali hizi na ujumbe unatumwa kutoka kwa iframe kwenda kwa popup kwa kutumia postMessage
, pande zote za kutuma na kupokea zina asili zao zimewekwa kwa null
. Hali hii inapelekea kwa hali ambapo e.origin == window.origin
inahesabiwa kuwa kweli (null == null
), kwa sababu iframe na popup zote zina thamani sawa ya asili ya null
.
Kwa habari zaidi soma:
pageBypassing SOP with Iframes - 1Kupita kwa e.source
Inawezekana kuthibitisha ikiwa ujumbe umetoka kwa dirisha sawa ambalo skripti inasikiliza (hasa ya kuvutia kwa Vitufe vya Yaliyomo kutoka kwa vifaa vya kivinjari kuthibitisha ikiwa ujumbe ulitumwa kutoka kwenye ukurasa sawa):
Unaweza kulazimisha e.source
ya ujumbe kuwa null kwa kuunda iframe ambayo inatuma postMessage na kufutwa mara moja.
Kwa maelezo zaidi soma:
pageBypassing SOP with Iframes - 2Kizuizi cha Kichwa cha X-Frame
Ili kutekeleza mashambulizi haya kwa njia bora, unaweza kuweka ukurasa wa mwathiriwa ndani ya iframe
. Lakini baadhi ya vichwa kama X-Frame-Header
vinaweza kuzuia tabia hiyo.
Katika hali hizo, bado unaweza kutumia shambulizi lenye utulivu mdogo. Unaweza kufungua kichupo kipya kwa programu dhaifu ya wavuti na kuwasiliana nayo:
Kuiba ujumbe uliotumwa kwa mtoto kwa kuzuia ukurasa kuu
Kwenye ukurasa ufuatao unaweza kuona jinsi unavyoweza kuiba data nyeti ya postmessage iliyotumwa kwa iframe ya mtoto kwa kuzuia ukurasa wa kuu kabla ya kutuma data na kutumia XSS katika mtoto kwa kuvuja kwa data kabla haijapokelewa:
pageBlocking main page to steal postmessageKuiba ujumbe kwa kubadilisha mahali pa iframe
Ikiwa unaweza kuweka iframe kwenye ukurasa bila Kichwa cha X-Frame kinachohitajika ambacho kina iframe nyingine, unaweza kubadilisha mahali pa ile iframe ya mtoto, hivyo ikiwa inapokea postmessage iliyotumwa kwa alama ya asterisk, mshambuliaji anaweza kubadilisha asili ya iframe hiyo kwenda kwenye ukurasa anaodhibiti na kuiba ujumbe huo:
pageSteal postmessage modifying iframe locationpostMessage kwa Uchafuzi wa Prototype na/au XSS
Katika mazingira ambapo data inayotumwa kupitia postMessage
inatekelezwa na JS, unaweza kuweka iframe kwenye ukurasa na kutumia uchafuzi wa prototype/XSS kutuma uchafuzi kupitia postMessage
.
Mifano ya XSS iliyoelezwa vizuri sana kupitia postMessage
inaweza kupatikana katika https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html
Mfano wa uchafuzi wa kutumia Uchafuzi wa Prototype na kisha XSS kupitia postMessage
kwa iframe
:
Kwa maelezo zaidi:
Kiungo kwa ukurasa kuhusu uchafuzi wa prototype
Kiungo kwa ukurasa kuhusu XSS
Kiungo kwa ukurasa kuhusu uchafuzi wa prototype wa upande wa mteja hadi XSS
Marejeo
Kwa mazoezi: https://github.com/yavolo/eventlistener-xss-recon
WhiteIntel ni injini ya utaftaji inayotumia dark-web ambayo inatoa huduma za bure kuchunguza ikiwa kampuni au wateja wake wameathiriwa na malware za kuiba.
Lengo kuu la WhiteIntel ni kupambana na utekaji wa akaunti na mashambulio ya ransomware yanayotokana na programu hasidi za kuiba taarifa.
Unaweza kutembelea tovuti yao na kujaribu injini yao bure kwa:
Last updated