Хакер - DOM XSS через Web Messaging. Как работает легкий способ получить XSS с помощью postMessage

Хакер - DOM XSS через Web Messaging. Как работает легкий способ получить XSS с помощью postMessage

hacker_frei

https://t.me/hacker_frei

W0lFreaK

Содержание статьи

  • Что такое DOM?
  • Как эксплуатируются DOM-based XSS?
  • Механизмы безопасности кросс-доменного взаимодействия
  • Web Messaging API
  • DOM-based XSS через Web Messaging
  • Origin Verification отсутствует
  • Origin verification
  • JSON Parse
  • Выводы

Не­дав­но я обна­ружил новую для себя раз­новид­ность XSS-уяз­вимос­тей — DOM XSS с помощью Web Messaging. Перечи­тав мно­жес­тво стра­ниц докумен­тации, я решил соз­дать еди­ный матери­ал по экс­плу­ата­ции XSS через эту тех­нологию. Я опи­шу здесь наибо­лее рас­простра­нен­ные недос­татки безопас­ности и методы их экс­плу­ата­ции.

ЧТО ТАКОЕ DOM?

DOM (Document Object Model) — не завися­щий от плат­формы и язы­ка прог­рам­мный интерфейс, который поз­воля­ет прог­раммам и скрип­там получать дос­туп к содер­жимому HTML-, XHTML-, XML-докумен­тов, а так­же изме­нять их кон­тент (содер­жимое, струк­туру, офор­мле­ние). DOM-based-уяз­вимос­ти воз­ника­ют, ког­да веб‑сайт содер­жит сце­нарий, который при­нима­ет кон­тро­лиру­емое зло­умыш­ленни­ком зна­чение и переда­ет его небезо­пас­ной фун­кции, называ­емой sink. Один из видов DOM-based-уяз­вимос­тей — DOM-based XSS. Уяз­вимос­ти это­го типа воз­ника­ют, ког­да JavaScript получа­ет дан­ные от поль­зовате­ля и переда­ет их в sink, обла­дающий воз­можностью динами­чес­кого исполне­ния кода, нап­ример eval(), document.write() или innerHTML.

КАК ЭКСПЛУАТИРУЮТСЯ DOM-BASED XSS?

На­ибо­лее популяр­ный источник DOM XSS — URL-стра­ницы. Дос­туп к это­му зна­чению осу­щест­вля­ется с помощью JavaScript через объ­ект window.location. Затем URL обра­баты­вает­ся внут­ри сущес­тву­юще­го на стра­нице легитим­ного скрип­та. В этом слу­чае ата­кующий может соз­дать ссыл­ку с вре­донос­ной наг­рузкой, что­бы затем отпра­вить ее жер­тве. Ког­да жер­тва перей­дет по ссыл­ке, исходный скрипт на стра­нице, исполь­зующий объ­ект window.location, зап­росит адрес текущей стра­ницы и исполнит наг­рузку, которая содер­жится в URL. Вот прос­тей­ший при­мер этой уяз­вимос­ти.

<body>

<script>document.write(location.href);</script>

</body>

При получе­нии такой стра­ницы бра­узер авто­мати­чес­ки выпол­нит скрипт и запишет в тело стра­ницы (document.write) стро­ку, взяв ее зна­чение из location.href (пол­ного адре­са стра­ницы). Одна­ко поль­зователь кон­тро­лиру­ет зна­чение location.href и может помес­тить в него про­изволь­ную стро­ку. Поэто­му для экс­плу­ата­ции XSS-уяз­вимос­ти дос­таточ­но сфор­мировать сле­дующую ссыл­ку, и при ее откры­тии в бра­узе­ре выпол­нится вре­донос­ный скрипт.

http://website.com/index.html#<script>alert(1)</script>

МЕХАНИЗМЫ БЕЗОПАСНОСТИ КРОСС-ДОМЕННОГО ВЗАИМОДЕЙСТВИЯ

Пред­ста­вим, что у нас есть стра­ница сай­та, который мы раз­работа­ли. Мы помеща­ем на нее эле­мент <iframe> и ука­зыва­ем в качес­тве его источни­ка про­изволь­ный сайт.

Прин­ципи­аль­ная схе­ма iframe

Ес­ли бы не было механиз­мов безопас­ности, обмен дан­ными меж­ду эле­мен­тами родитель­ской веб‑стра­ницы и веб‑стра­ницы, которая отоб­ража­ется в <iframe>, мог бы быть кри­тичес­ки опас­ным для поль­зователь­ских дан­ных. Любой скрипт, находя­щий­ся на родитель­ской стра­нице, мог бы получить дос­туп к любым дан­ным, раз­мещен­ным внут­ри <iframe>.

Да­вай рас­смот­рим на при­мере. Зло­умыш­ленник помеща­ет на сво­ей стра­нице <iframe> с адре­сом интернет‑бан­ка, в котором поль­зователь был авто­ризо­ван ранее. Затем каким‑то обра­зом замани­вает жер­тву на свою стра­ницу. В резуль­тате зло­умыш­ленник может получить дос­туп к любым поль­зователь­ским дан­ным лич­ного кабине­та интернет‑бан­ка жер­твы. Что­бы не допус­тить подоб­ного, были соз­даны два механиз­ма защиты:

  1. Same Origin Policy (SOP), «полити­ка оди­нако­вого источни­ка», — пре­дот­вра­щает кросс‑домен­ные ата­ки, бло­кируя чте­ние заг­ружа­емых ресур­сов из дру­гого источни­ка. Источник иден­тифици­рует­ся по сле­дующей трой­ке парамет­ров: схе­ма, пол­ное имя хос­та и порт. Ког­да хотя бы один из парамет­ров у источни­ков не сов­пада­ет, обмен дан­ными меж­ду ресур­сами зап­реща­ется. Нап­ример, если стра­ница по адре­су http://example.com/index.html поп­робу­ет отоб­разить дан­ные из источни­ка https://example.com/, то это дей­ствие будет зап­рещено, так как у источни­ков не сов­пада­ет про­токол.
Same Origin Policy

2. Cross-Origin Resource Sharing. Огра­ниче­ния полити­ки оди­нако­вых источни­ков ока­зались слиш­ком жес­тки­ми. Поэто­му для более тон­кой нас­трой­ки дос­тупа к ресур­сам соз­дали «механизм сов­мес­тно­го исполь­зования ресур­сов раз­ными источни­ками» — CORS. Он рег­ламен­тиру­ет три катего­рии сетево­го вза­имо­дей­ствия:

  • за­пись из раз­ных источни­ков. Эта катего­рия рег­ламен­тиру­ет пере­адре­сации, отправ­ки форм и перехо­ды по ссыл­кам. По умол­чанию все эти дей­ствия раз­решены;
  • встав­ка из раз­ных источни­ков. Эта катего­рия рег­ламен­тиру­ет эле­мен­ты, заг­ружа­емые пос­редс­твом тегов <link>, <script>, <img>, <video>, <audio>, <iframe> и дру­гих. По умол­чанию все они раз­решены, одна­ко работос­пособ­ность тега <iframe> может быть допол­нитель­но огра­ниче­на с помощью заголов­ка X-Frame-Options;
  • счи­тыва­ние из раз­ных источни­ков. Эта катего­рия рег­ламен­тиру­ет эле­мен­ты, заг­ружа­емые через AJAX и fetch. По умол­чанию эти воз­можнос­ти заб­локиро­ваны.

WWW

Под­робнее о CORS и SOP ты можешь про­читать, к при­меру, в этих стать­ях на «Хаб­рахаб­ре»: «CORS для чай­ников: исто­рия воз­никно­вения, как устро­ен и опти­маль­ные методы работы» и «По­лити­ка обще­го про­исхожде­ния и CORS: визу­аль­ное руководс­тво».

WEB MESSAGING API

Window.postMessage() — это метод, поз­воля­ющий переда­вать дан­ные меж­ду докумен­тами, которые заг­ружены в раз­ных окнах или фрей­мах, в том чис­ле меж­ду докумен­тами, получен­ными с раз­ных доменов. Если на сай­те кор­рек­тно нас­тро­ены механиз­мы безопас­ности (SOP и CORS), исполь­зование postMessage будет единс­твен­ным дос­тупным спо­собом переда­чи дан­ных меж­ду докумен­тами на раз­ных доменах. Зап­росы, соз­данные с помощью про­чих методов (как, нап­ример, XMLHttpRequest или Fetch API), будут заб­локиро­ваны в соот­ветс­твии с SOP и CORS.

По­иск информа­ции о тех­нологии postMessages при­вел меня к офи­циаль­ной докумен­тации Mozilla. Обыч­но сце­нари­ям из раз­ных источни­ков раз­решен дос­туп друг к дру­гу тог­да и толь­ко тог­да, ког­да они соот­ветс­тву­ют Same Origin Policy (оди­нако­вая схе­ма, имя хос­та и порт), вклю­чая сце­нарии внут­ри фрей­ма, которые обра­щают­ся к родите­лю фрей­ма. Window.postMessage() пре­дос­тавля­ет кон­тро­лиру­емый механизм для безопас­ного обхо­да это­го огра­ниче­ния. Так­же я нашел в докумен­тации спо­собы обес­печения свя­зи меж­ду родитель­ской стра­ницей и стра­ницей внут­ри фрей­ма. В общем виде дочер­ний <iframe> дол­жен быть под­писан на событие «сооб­щение»:

window.addEventListener("message", (event) => {...}, false);

Здесь message — ожи­даемое сооб­щение.

В таком слу­чае родитель­ская стра­ница может передать дочер­нему фрей­му сооб­щение с помощью такого метода:

postMessage(message, targetOrigin, transfer)

Здесь message — отправ­ляемое сооб­щение, эти дан­ные авто­мати­чес­ки сери­али­зуют­ся для переда­чи в дочер­ний фрейм, а targetOrigin ука­зыва­ет источник родитель­ско­го окна.

В качес­тве targetOrigin допус­кает­ся исполь­зовать звез­дочку, которая ука­зыва­ет на то, что получить сооб­щение может кто угод­но. Либо мож­но ука­зать кон­крет­ный URI, который будет про­верен внут­ри слу­шате­ля в дочер­нем фрей­ме. Если Origin стра­ницы не сов­пада­ет с targetOrigin внут­ри этой фун­кции, событие не будет отправ­лено. Этот механизм обес­печива­ет кон­троль над тем, куда отправ­ляют­ся сооб­щения. Нап­ример, если postMessage исполь­зует­ся для отправ­ки пароля, необ­ходимо, что­бы этот аргу­мент соот­ветс­тво­вал целево­му URI. Это поз­волит пре­дот­вра­тить хищение пароля зло­умыш­ленни­ком через недове­рен­ный ресурс. 

DOM-BASED XSS ЧЕРЕЗ WEB MESSAGING

Да­вай пос­мотрим, как мож­но исполь­зовать веб‑сооб­щения в качес­тве источни­ка для соз­дания и экс­плу­ата­ции DOM XSS на целевой стра­нице. Если целевая стра­ница обра­баты­вает вхо­дящие сооб­щения небезо­пас­ным обра­зом (нап­ример, невер­но про­веряя источник вхо­дящих сооб­щений), то вызыва­емые слу­шате­лем события потен­циаль­но могут стать при­емни­ками небезо­пас­ной наг­рузки и источни­ком XSS.

Нап­ример, зло­умыш­ленник может помес­тить на сво­ей стра­нице вре­донос­ный <iframe> и исполь­зовать метод postMessage() для переда­чи дан­ных с помощью веб‑сооб­щения уяз­вимому слу­шате­лю событий. В даль­нейшем слу­шатель передаст вре­донос­ную наг­рузку в при­емник на дочер­ней стра­нице.

Это зна­чит, что веб‑сооб­щения могут быть исполь­зованы в качес­тве источни­ка наг­рузки для любого из при­емни­ков дочер­ней веб‑стра­ницы. Резуль­тат экс­плу­ата­ции уяз­вимос­ти зависит от того, как целевой документ обра­баты­вает получен­ные сооб­щения.

Ес­ли целевая стра­ница пол­ностью доверя­ет отпра­вите­лю, не про­веря­ет дан­ные, получен­ные от него, и без иска­жений переда­ет их в при­емник, то эта уяз­вимость поз­волит зло­умыш­ленни­ку совер­шить любые дей­ствия от лица поль­зовате­ля в кон­тек­сте целево­го ресур­са (ском­про­мети­ровать поль­зовате­ля).

Да­вай рас­смот­рим раз­ные вари­анты уяз­вимого кода.

Origin Verification отсутствует

Це­левая стра­ница легитим­ного сай­та содер­жит сле­дующий скрипт.

<script>

window.addEventListener('message', function(e){

document.getElementById('qwe').innerHTML = e.data;

})

</script>

В этом слу­чае экс­плу­ата­ция уяз­вимос­ти воз­можна с помощью <iframe>, помещен­ного на сер­вере ата­кующе­го, при­мер­но с таким содер­жимым:

<iframe src="http://target.com/" onload="this.contentWindow.postMessage('<img src=1 onerror=alert`1`>','*')">

Как видишь, слу­шатель сооб­щений не про­веря­ет источник, а метод postMessage ука­зыва­ет targetOrigin «звез­дочка». Про­цесс экс­плу­ата­ции будет выг­лядеть так:

  • postMessage() в пей­лоаде соз­даст сооб­щение, которое отпра­вит­ся стра­нице в <iframe> пос­ле того, как заг­рузит­ся содер­жимое <iframe>;
  • EventListener целевой стра­ницы получит сооб­щение с ата­кующей стра­ницы;
  • EventListener выпол­нит поиск эле­мен­та с ID qwe;
  • EventListener выпол­нит встав­ку получен­ного сооб­щения в най­ден­ный тег <div>;
  • в ито­ге в целевую стра­ницу будет встав­лен тег img, содер­жащий некор­рек­тный адрес источни­ка. Это вызовет ошиб­ку, а обра­бот­ка этой ошиб­ки исполнит про­изволь­ный код, ука­зан­ный ата­кующим, то есть вызовет alert(1). 

Origin verification

Пред­ста­вим, что целевая стра­ница легитим­ного сай­та содер­жит такой скрипт:

window.addEventListener('message', function(e) {

if (e.origin.indexOf('normal-website.com') > -1) {

eval(e.data);

}

});

В том слу­чае, если слу­шатель про­веря­ет Origin, могут най­тись проб­лемы в реали­зации этих про­верок. Нап­ример, про­вер­ку с помощью метода indexOf мож­но обой­ти, если сде­лать вре­донос­ный скрипт на мно­гоуров­невом домене, содер­жащем в себе иско­мую подс­тро­ку. Нап­ример, таком:

<http://www.normal-website.com.attacker.com>

Ана­логич­ным обра­зом обхо­дят­ся про­вер­ки, которые выпол­няют­ся пос­редс­твом методов startsWith(), endsWith() и дру­гих.

JSON Parse

Не­ред­ки слу­чаи, ког­да слу­шатель может выпол­нить одно из нес­коль­ких заранее ука­зан­ных дей­ствий, в зависи­мос­ти от того, какое имен­но сооб­щение он получит при выпол­нении postMessage. Под­разуме­вает­ся, что дочер­ний фрейм смо­жет по‑раз­ному реаги­ровать на раз­личные сооб­щения, при­ходя­щие из родитель­ско­го эле­мен­та. Эта вари­атив­ность дей­ствий будет опи­сана в дочер­нем <iframe> подоб­ным скрип­том:

<script>

window.addEventListener('message', function(e) {

var iframe = document.createElement('iframe'), ACMEplayer = {element: iframe}, d;

document.body.appendChild(iframe);

try {

d = JSON.parse(e.data);

} catch(e) {

return;

}

switch(d.type) {

case "img":

ACMEplayer.element.src = d.url;

break;

case "redirect":

window.location.replace(d.redirectUrl);

break;

}

}, false);

</script>

В дан­ном слу­чае в зависи­мос­ти от сооб­щения, получа­емо­го дочер­ним iframe, он может выпол­нить одно из двух дей­ствий:

  1. Ес­ли в резуль­тате вызова postMessage в дочер­ний iframe переда­но сооб­щение, содер­жащее {"type" : "img", "url" : "https://domain.com"}, дочер­ний iframe прис­воит ука­зан­ный URL свой­ству src эле­мен­та ACMEplayer отоб­ража­емой в нем стра­ницы.
  2. Ес­ли в резуль­тате вызова postMessage в дочер­ний iframe переда­но сооб­щение, содер­жащее {"type" : "redirect", "url" : "https://domain.com"}, то дочер­нийiframe выпол­нит переход с текущей стра­ницы на ука­зан­ный URL.

Для экс­плу­ата­ции уяз­вимос­ти необ­ходимо сфор­мировать кор­рек­тный JSON-объ­ект, который будет передан в дочер­ний фрейм и пра­виль­но обра­ботан внут­ренним эле­мен­том case. При­мер вре­донос­ной наг­рузки:

<iframe src=https://victim.com/ onload='this.contentWindow.postMessage("{"type":"img","url":"javascript:alert(1)"}","*")'>

В резуль­тате отправ­ки такого сооб­щения у эле­мен­та ACMEplayer в src будет уста­нов­лено зна­чение, соот­ветс­тву­ющее URL из нашей вре­донос­ной наг­рузки. Пос­коль­ку вто­рой аргу­мент ука­зыва­ет, что любой targetOrigin раз­решен для postMessage, а обра­бот­чик событий не содер­жит какой‑либо фор­мы про­вер­ки источни­ка, полез­ная наг­рузка будет уста­нов­лена и исполне­на, ког­да жер­тва перей­дет на эту стра­ницу. 

ВЫВОДЫ

Мы под­робно разоб­рали уяз­вимос­ти, которые воз­ника­ют при неак­курат­ном обра­щении с Web Messaging API для орга­низа­ции переда­чи дан­ных меж­ду родитель­ской стра­ницей и заг­ружа­емой внут­ри <iframe>. Вот нес­коль­ко рекомен­даций, которые поз­волят избе­жать подоб­ных проб­лем на сво­ем сай­те:

  • про­веряй ори­гиналь­ность источни­ка сооб­щения, что­бы пре­дот­вра­тить внед­рение конс­трук­ций с недове­рен­ных сай­тов;
  • ис­поль­зуй безопас­ные спо­собы про­вер­ки под­линнос­ти ори­гиналь­ного источни­ка сооб­щения;
  • про­веряй сооб­щения на наличие потен­циаль­но опас­ных содер­жаний и команд перед их выпол­нени­ем;
  • ис­поль­зуй механиз­мы шиф­рования для защиты кон­фиден­циаль­нос­ти сооб­щений во вре­мя переда­чи.

Ну а если ты пен­тестер, а не веб‑дизай­нер, то не забудь про­верить эти тех­ники, ког­да встре­тишь веб‑сооб­щения.

Читайте ещё больше платных статей бесплатно: https://t.me/hacker_frei



Report content on this page

Report Page

Please submit your DMCA takedown request to dmca@telegram.org