PostMessage Vulnerabilities
PostMessage Kw vulnerabilities
Stuur PostMessage
PostMessage gebruik die volgende funksie om 'n boodskap te stuur:
Let wel, targetOrigin kan 'n '*' of 'n URL soos https://company.com. wees. In die tweede scenario kan die boodskap slegs na daardie domein gestuur word (selfs al is die oorsprong van die venster objek anders). As die wildcard gebruik word, kan boodskappe na enige domein gestuur word, en sal dit na die oorsprong van die Window objek gestuur word.
Aanval op iframe & wildcard in targetOrigin
Soos verduidelik in hierdie verslag, as jy 'n bladsy vind wat iframed kan word (geen X-Frame-Header
beskerming nie) en wat sensitiewe boodskap via postMessage met 'n wildcard (*) stuur, kan jy die oorsprong van die iframe wysig en die sensitiewe boodskap na 'n domein wat deur jou beheer word lek.
Let wel, as die bladsy iframed kan word maar die targetOrigin is gestel op 'n URL en nie op 'n wildcard nie, sal hierdie truuk nie werk nie.
addEventListener eksploitering
addEventListener
is die funksie wat deur JS gebruik word om die funksie te verklaar wat verwag postMessages
.
'n Kode soortgelyk aan die volgende een sal gebruik word:
Note in hierdie geval hoe die eerste ding wat die kode doen is om die oorsprong te kontroleer. Dit is vreeslik belangrik veral as die bladsy enigiets sensitiefs met die ontvangde inligting gaan doen (soos om 'n wagwoord te verander). As dit nie die oorsprong kontroleer nie, kan aanvallers slagoffers dwing om arbitrêre data na hierdie eindpunte te stuur en die slagoffers se wagwoorde te verander (in hierdie voorbeeld).
Enumerasie
Om gebeurtenisluisteraars in die huidige bladsy te vind kan jy:
Soek die JS-kode vir
window.addEventListener
en$(window).on
(JQuery weergawe)Voer in die ontwikkelaarstoele console uit:
getEventListeners(window)
Gaan na Elements --> Event Listeners in die ontwikkelaarstoele van die blaaier
Gebruik 'n blaaier uitbreiding soos https://github.com/benso-io/posta of https://github.com/fransr/postMessage-tracker. Hierdie blaaier uitbreidings sal alle boodskappe onderskep en dit aan jou wys.
Oorsprong kontroleer omseilings
event.isTrusted
attribuut word as veilig beskou aangesien ditTrue
slegs teruggee vir gebeurtenisse wat deur werklike gebruikersaksies gegenereer word. Alhoewel dit uitdagend is om te omseil as dit korrek geïmplementeer is, is die belangrikheid daarvan in sekuriteitskontroles noemenswaardig.Die gebruik van
indexOf()
vir oorsprong validasie in PostMessage gebeurtenisse mag vatbaar wees vir omseiling. 'n Voorbeeld wat hierdie kwesbaarheid illustreer is:
Die
search()
metode vanString.prototype.search()
is bedoel vir gereelde uitdrukkings, nie strings nie. Om enigiets anders as 'n regexp oor te dra lei tot implisiete omskakeling na regex, wat die metode potensieel onveilig maak. Dit is omdat in regex, 'n punt (.) as 'n wildcard optree, wat omseiling van validasie met spesiaal saamgestelde domeine moontlik maak. Byvoorbeeld:
Die
match()
funksie, soortgelyk aansearch()
, verwerk regex. As die regex verkeerd gestruktureer is, mag dit vatbaar wees vir omseiling.Die
escapeHtml
funksie is bedoel om insette te saniteer deur karakters te ontsnap. Dit skep egter nie 'n nuwe ontsnapte objek nie, maar oorskryf die eienskappe van die bestaande objek. Hierdie gedrag kan uitgebuit word. Veral, as 'n objek gemanipuleer kan word sodat sy beheerde eienskap niehasOwnProperty
erken nie, sal dieescapeHtml
nie soos verwag werk nie. Dit word in die voorbeelde hieronder gedemonstreer:Verwachte Faal:
Omseiling van die ontsnapping:
In die konteks van hierdie kwesbaarheid is die File
objek merkwaardig uitbuitbaar weens sy leesbare name
eienskap. Hierdie eienskap, wanneer in sjablone gebruik, word nie deur die escapeHtml
funksie gesaniteer nie, wat lei tot potensiële sekuriteitsrisiko's.
Die
document.domain
eienskap in JavaScript kan deur 'n skrip gestel word om die domein te verkort, wat 'n meer ontspanne same oorsprong beleid afdwinging binne die selfde ouerdomein moontlik maak.
e.origin == window.origin omseiling
Wanneer 'n webblad binne 'n sandboxed iframe ingebed word met %%%%%%, is dit van kardinale belang om te verstaan dat die iframe se oorsprong op null gestel sal word. Dit is veral belangrik wanneer daar met sandbox eienskappe en hul implikasies op sekuriteit en funksionaliteit gewerk word.
Deur allow-popups
in die sandbox eienskap te spesifiseer, erf enige pop-up venster wat vanuit die iframe geopen word die sandbox beperkings van sy ouer. Dit beteken dat tensy die allow-popups-to-escape-sandbox
eienskap ook ingesluit is, die pop-up venster se oorsprong ook op null
gestel word, wat ooreenstem met die iframe se oorsprong.
Gevolglik, wanneer 'n pop-up onder hierdie omstandighede geopen word en 'n boodskap van die iframe na die pop-up gestuur word met postMessage
, het beide die sending en ontvangende kante hul oorsprong op null
gestel. Hierdie situasie lei tot 'n scenario waar e.origin == window.origin
waar is (null == null
), omdat beide die iframe en die pop-up die selfde oorsprong waarde van null
deel.
Vir meer inligting lees:
Bypassing SOP with Iframes - 1Omseiling van e.source
Dit is moontlik om te kontroleer of die boodskap van dieselfde venster afkomstig is waar die skrip na luister (spesiaal interessant vir Inhoud Skrifte van blaaier uitbreidings om te kontroleer of die boodskap van dieselfde bladsy gestuur is):
U kan e.source
van 'n boodskap dwing om null te wees deur 'n iframe te skep wat die postMessage stuur en dadelik verwyder word.
Vir meer inligting lees:
Bypassing SOP with Iframes - 2X-Frame-Header omseiling
Om hierdie aanvalle uit te voer, sal dit ideaal wees om die slagoffer webblad binne 'n iframe
te kan plaas. Maar sommige koptekste soos X-Frame-Header
kan daardie gedrag voorkom.
In daardie scenario's kan u steeds 'n minder stealthy aanval gebruik. U kan 'n nuwe oortjie oopmaak na die kwesbare webtoepassing en met dit kommunikeer:
Dief van boodskap wat na kind gestuur is deur die hoofblad te blokkeer
In die volgende bladsy kan jy sien hoe jy 'n sensitiewe postmessage data wat na 'n kind iframe gestuur is, kan steel deur die hoof bladsy te blokkeer voordat die data gestuur word en 'n XSS in die kind te misbruik om die data te lek voordat dit ontvang word:
Blocking main page to steal postmessageDief van boodskap deur iframe ligging te verander
As jy 'n webblad kan iframe sonder X-Frame-Header wat 'n ander iframe bevat, kan jy die ligging van daardie kind iframe verander, so as dit 'n postmessage ontvang wat met 'n wildcard gestuur is, kan 'n aanvaller daardie iframe oorsprong na 'n bladsy gebeheer deur hom verander en die boodskap steel:
Steal postmessage modifying iframe locationpostMessage na Prototype Pollution en/of XSS
In scenario's waar die data wat deur postMessage
gestuur word, deur JS uitgevoer word, kan jy die bladsy iframe en die prototype pollution/XSS ontgin deur die eksploiet via postMessage
te stuur.
'n Paar baie goed verduidelikde XSS deur postMessage
kan gevind word in https://jlajara.gitlab.io/web/2020/07/17/Dom_XSS_PostMessage_2.html
Voorbeeld van 'n eksploiet om Prototype Pollution en dan XSS deur 'n postMessage
na 'n iframe
te misbruik:
For meer inligting:
Skakel na bladsy oor prototype besoedeling
Skakel na bladsy oor XSS
Skakel na bladsy oor kliëntkant prototype besoedeling na XSS
Verwysings
Om te oefen: https://github.com/yavolo/eventlistener-xss-recon
Last updated