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

Web Messaging API

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

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

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

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

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

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

DOM-based XSS через Web Messaging

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

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

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

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

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

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