OAuth от и до

Ты, нап­ример, мог слы­шать про Open Redirect, который час­то не вос­при­нима­ют всерь­ез и за обна­руже­ние которо­го не пла­тят Bug Bounty. Но если ты смо­жешь най­ти спо­соб кра­сиво заюзать его и повысить импакт до кра­жи акка­унта, это уже сов­сем дру­гое дело.

Что будет, если не проверять redirect_uri

Пер­вый кейс прос­той. redirect_uri — это тот параметр, который говорит сер­веру авто­риза­ции, на какой URL ему нуж­но нап­равить токен пос­ле того, как поль­зователь вой­дет через соци­аль­ную сеть и сог­ласит­ся дать дос­туп к сво­им ресур­сам.

При­ложе­ние на пер­вом эта­пе авто­риза­ции по OAuth, или, в тер­миноло­гии спе­ки, эта­пе Authorization Request, фор­миру­ет ссыл­ку и ука­зыва­ет в качес­тве это­го парамет­ра под­кон­троль­ный ему эндпо­инт.

Ког­да ты вхо­дишь через Discord на сайт Midjourney, ссыл­ка выг­лядит при­мер­но так:

В этом зап­росе говорит­ся о том, что в кон­це флоу сер­вер авто­риза­ции не толь­ко выда­ет код, но и дол­жен вер­нуть поль­зовате­ля на сайт при­ложе­ния midjourney.com/oauth2/authorize.

По‑хороше­му в парамет­ре redirect_uri дол­жен быть вай­тлист ссы­лок, на которые мож­но редирек­тить. Такие ссыл­ки обыч­но ука­зыва­ет вла­делец при­ложе­ния, ког­да его регис­три­рует. Это поз­воля­ет обру­бать зап­рос, если кто‑то под­ста­вит свой redirect_uri.

Ес­ли вай­тлис­та нет, это соз­дает прос­транс­тво для манипу­ляций. Зло­умыш­ленник может взять ссыл­ку из пер­вого эта­па и заменить в ней redirect_uri под­кон­троль­ным ему сер­висом, выложить ее где‑нибудь в соци­аль­ных сетях и украсть токен пос­ле того, как кто‑нибудь уже авто­ризо­ван­ный в Discord и в Midjourney перей­дет по ней (то же спра­вед­ливо и для дру­гих пар при­ложе­ний и OAuth-про­вай­деров).

Сей­час мы раз­берем это под­робнее на реаль­ном при­мере.

Лаба: OAuth account hijacking via redirect_uri

• Ла­бора­тор­ная работа на сай­те PortSwigger

Стар­туем и ока­зыва­емся на глав­ной стра­нице со стран­ной кар­тинкой.

Как и рань­ше, про­ходим весь флоу с логином, что­бы соб­рать все зап­росы и спо­кой­но про­ана­лизи­ровать их. Заходим под акка­унтом wiener.

И ока­зыва­емся в лич­ном кабине­те.

Флоу авто­риза­ции прой­ден, перехо­дим в Burp. Находим Authorization Request (тот зап­рос на сер­вер авто­риза­ции, на который нас перенап­равило при­ложе­ние) и отправ­ляем его в Repeater.

Имен­но в этой ссыл­ке есть уяз­вимый redirect_uri, который мы и будем экс­плу­ати­ровать.

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

Пос­мотрим, как это про­исхо­дит на прак­тике. Меня­ем в нашем зап­росе тот URI, который был ука­зан, на адрес экс­пло­ит‑сер­вера. Он выда­ется в лабора­тори­ях вро­де этой, и его мож­но най­ти в вер­хнем меню.

Пе­рехо­ди туда, копируй ссыл­ку и встав­ляй ее в качес­тве парамет­ра redirect_uri.

У меня это выг­лядит так.

Мож­но нажать пра­вой кноп­кой мыши и выб­рать Copy URL, что­бы ско­пиро­вать всю ссыл­ку и пос­мотреть в бра­узе­ре, как про­изой­дет редирект и в логах появит­ся наш токен.

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

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

У меня получи­лось так.

Встав­ляем HTML-раз­метку в поле Body и сох­раня­ем кноп­кой Store.

Те­перь у нас есть стра­ница, на которую может зай­ти адми­нис­тра­тор, и тог­да мы укра­дем его учет­ку. При посеще­нии стра­ницы про­изой­дет цепоч­ка редирек­тов для авто­риза­ции. Пос­коль­ку он уже залоги­нен в соци­аль­ной сети, в кон­це кон­цов он будет перенап­равлен на наш сер­вер, где мы и залоги­руем его OAuth-токен из URL.

На­жима­ем Deliver exploit to victim. В зависи­мос­ти от наг­рузки на сер­веры PortSwigger зап­рос может прий­ти с неболь­шой задер­жкой. Мне приш­лось подож­дать нес­коль­ко минут (в течение которых я жал одну и ту же кноп­ку), и в кон­це кон­цов мне при­лете­ло нес­коль­ко десят­ков зап­росов с токеном адми­нис­тра­тора.

Ко­пиру­ем пос­ледний при­шед­ший токен и встав­ляем в зап­рос /oauth-callback. Если все прой­дет нор­маль­но, сер­вер дол­жен отдать куки и показать, что мы залоги­нены. Так и про­изош­ло. Появи­лась ссыл­ка на панель адми­нис­тра­тора, а это зна­чит, что мы не прос­то заш­ли, а заш­ли как админ.

За­ходим через бра­узер, уда­ляем поль­зовате­ля carlos и нас­лажда­емся победой над еще одной лабой.

Злоупотребление открытым редиректом в связке с OAuth

Да­вай крат­ко вспом­ним, что вооб­ще такое Open Redirect.

Нап­ример, у нас есть сайт Google. Он не нуж­дает­ся в пред­став­лении, у него боль­шой кре­дит доверия, и все ком­пании счи­тают, что домен google.com безопас­ный, поэто­му дают ему некото­рые пос­лабле­ния, добав­ляя в собс­твен­ные белые спис­ки.

Но если зло­умыш­ленни­ки най­дут на нем Open Redirect, то они смо­гут вос­поль­зовать­ся этим довери­ем и исполь­зовать его, что­бы соз­дать ссыл­ку на собс­твен­ный C2-сер­вер, обхо­дя детек­тирова­ние некото­рых анти­виру­сов.

Вот при­мер такой ссыл­ки:

Она была бы уяз­вимой, если бы сра­зу нап­равля­ла на ука­зан­ный сайт. Хорошим тоном счи­тает­ся пре­дуп­реждать поль­зовате­ля, что он покида­ет легитим­ный сайт, и не выпол­нять редирект без его сог­ласия.

Сам по себе Open Redirect не очень опа­сен, кро­ме пог­ранич­ного слу­чая, свя­зан­ного с вре­доно­сами, который я опи­сал выше. Но его час­то исполь­зуют в связ­ке с экс­плу­ата­цией дру­гих веб‑уяз­вимос­тей, ког­да он ста­новит­ся по‑нас­тояще­му гроз­ным ору­жием, поз­воля­ющим обхо­дить мно­гие филь­тры, заточен­ные на про­вер­ку по регуляр­ке или подс­тро­ке.

К при­меру, сайт может про­верять, что redirect_uri начина­ется толь­ко с https://example.com. Если на этом example.com получит­ся най­ти Open Redirect, то мож­но будет и прой­ти про­вер­ку, и экс­плу­ати­ровать уяз­вимость, что­бы украсть токен через OAuth.

Лаба: Stealing OAuth access tokens via an open redirect

• Ла­бора­тор­ная работа на сай­те PortSwigger

Как всег­да, откры­ваем лабора­торию и попада­ем на глав­ную стра­ницу бло­га.

Ло­гиним­ся через соци­аль­ную сеть.

Смот­рим исто­рию зап­росов, берем Authorization Request и пыта­емся пов­торить трюк из пре­дыду­щей лабы — для это­го заменя­ем redirect_uri каким‑нибудь сво­им, нап­ример адре­сом экс­пло­ит‑сер­вера.

От­прав­ляем зап­рос и видим в отве­те текст error: redirect_uri_mismatch, который озна­чает, что на этот раз мы не смо­жем так наг­ло, как рань­ше, заменить этот параметр и украсть токен.

Нем­ного покопав­шись на сай­те, находим в самом низу стра­ницы записи из бло­га две ссыл­ки: на пре­дыду­щую запись и сле­дующую (если она есть).

Выг­лядит ссыл­ка сле­дующим обра­зом:

Как мож­но заметить, у нее есть параметр path, где ука­зан путь, по которо­му нуж­но сде­лать редирект. Что, если бы мы мог­ли поп­робовать экс­плу­ати­ровать здесь Open Redirect и перенап­равить поль­зовате­ля на любой дру­гой сайт или даже собс­твен­ный вре­донос­ный сер­вер?

За­меня­ем redirect_uri сво­ей ссыл­кой:

От­прав­ляем зап­рос и сно­ва стал­кива­емся с той же самой ошиб­кой. Видимо, сер­вер про­веря­ет не толь­ко домен, на который мы редирек­тим, но и сам путь.

Пу­тем экспе­римен­тов выяс­няем, что ссыл­ка обя­затель­но дол­жна начинать­ся так:

Мы можем допол­нитель­но экс­плу­ати­ровать Path Traversal, что­бы удов­летво­рять пра­вилам. Фор­миру­ем сле­дующую ссыл­ку и пыта­емся сно­ва отпра­вить зап­рос с изме­нен­ным redirect_uri:

Сра­бота­ло!

• /../ пос­ле oauth-callback обоз­нача­ет, что мы перехо­дим на уро­вень выше к кор­ню сай­та (экс­плу­ати­руя Path Traversal);
• post/next?path=https://google.com — исполь­зуем URL для перехо­да к сле­дующе­му пос­ту с собс­твен­ным path=https://google.com, что­бы отпра­вить поль­зовате­ля на сто­рон­ний сайт.

Ко­пиру­ем получен­ный URL, откры­ваем в бра­узе­ре, и вот наш токен про­кинул­ся на тот сайт, который мы ука­зали.

Те­перь вмес­то google.com мы можем пос­тавить ссыл­ку на собс­твен­ный сер­вер и украсть токен. Но пот­ребу­ются еще неболь­шие доработ­ки. Мож­но заметить, что токен переда­ется не через при­выч­ный GET-параметр пос­ле зна­ка воп­роса, а как якорь (то есть идет пос­ле решет­ки). Обыч­но сер­веры не логиру­ют такие парамет­ры, потому что они пред­назна­чены толь­ко для бра­узе­ра.

Со­ответс­твен­но, обра­баты­вает­ся токен толь­ко на сто­роне кли­ента, и нам нуж­но извлечь его. Делать это мы будем с помощью прос­тень­кого кода на JavaScript.

Вот что будет делать наш скрипт:

1. Ес­ли поль­зователь зашел впер­вые — отпра­вит его на вход через соци­аль­ную сеть с нашим вре­донос­ным урлом.
2. Ес­ли поль­зователь вер­нулся по URL, который был ука­зан в пер­вом пун­кте, извле­кает токен и отправ­ляет его на этот же URL, но уже с нор­маль­но задан­ным GET-парамет­ром, который залоги­рует­ся:

По­меща­ем скрипт на свой экс­пло­ит‑сер­вер и нажима­ем Deliver exploit to victim.

Ждем пару секунд и про­веря­ем логи, где и находим зап­рос с токеном.

Те­перь у нас есть OAuth-токен адми­нис­тра­тора. Из исто­рии зап­росов находим зап­рос к API /me. Этот эндпо­инт отда­ет информа­цию о вла­дель­це токена.

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

Ко­пиру­ем его, встав­ляем в Submit solution.

Под­твержда­ем отправ­ку и при­нима­ем поз­драв­ления.

Формируем цепочки багов для повышения импакта

Как быть, если мы не смог­ли най­ти ни одну из оши­бок, о которых я рас­ска­зал выше? Уяз­вимос­ти типа Open Redirect и CSRF, которые мы экс­плу­ати­рова­ли в ком­бинации с клас­сичес­кими ата­ками на OAuth, не единс­твен­ные, которые тут могут быть полез­ны.

У OAuth мно­го воз­можнос­тей и откро­вен­ных багов, которые может исполь­зовать зло­умыш­ленник, что­бы украсть токен. Одна­ко в слу­чае более слож­ных при­ложе­ний ему (и тебе — как пен­тесте­ру) пот­ребу­ется нем­ного фан­тазии.

Вот нес­коль­ко хороших при­меров:

• XSS-уяз­вимос­ти — на веб‑сер­верах мож­но встре­тить атри­бут httpOnly, который прос­тавля­ется сес­сион­ной куке, что­бы ее нель­зя было украсть с помощью уяз­вимос­тей меж­сай­тового скрип­тинга. Пом­ни, что код авто­риза­ции OAuth не име­ет такой защиты, и ты можешь вос­поль­зовать­ся этим, что­бы украсть чужой акка­унт. Так ты смо­жешь повысить импакт и украсть акка­унт адми­на, даже если на сер­висе исполь­зует­ся httpOnly.
• HTML-инъ­екции — ког­да нель­зя внед­рить пол­ноцен­ный код на JavaScript или в при­ложе­нии исполь­зует­ся стро­гая полити­ка CSP, отча­ивать­ся не сто­ит — для кра­жи кода авто­риза­ции может хва­тить даже прос­той инъ­екции. К при­меру, если ты кон­тро­лиру­ешь ввод атри­бута src у эле­мен­та img (то есть ссыл­ку на кар­тинку), то мож­но узнать код с помощью атри­бута Referer (он сиг­нализи­рует, с какого сай­та при­шел поль­зователь). Некото­рые бра­узе­ры (вро­де Firefox) отправ­ляют Referer пол­ностью при заг­рузке кар­тинок, вклю­чая всю стро­ку зап­роса.
• Опас­ный JavaScript, обра­баты­вающий весь URL или отдель­ные парамет­ры зап­роса. Тут нуж­но нем­ного подумать и рас­кру­тить цепоч­ку, которая при­ведет к завет­ной цели.

Сей­час мы на прак­тике реали­зуем опас­ную цепоч­ку гад­жетов, где исполь­зование PostMessage ста­ло фаталь­ным и поз­волило украсть чужой токен.

Как работает PostMessage

PostMessage — этот механизм, который поз­воля­ет безопас­но отправ­лять кросс‑домен­ные зап­росы.

Обыч­но дос­туп к ресур­сам на раз­ных стра­ницах раз­решен толь­ко в том слу­чае, если стра­ницы име­ют один и тот же origin, то есть «про­исхожде­ние», которое опре­деля­ется по ком­бинации про­токо­ла (нап­ример, HTTPS), номера пор­та (443 — по умол­чанию для HTTPS) и хос­та (домен­ного име­ни).

Это часть механиз­ма безопас­ности бра­узе­ра, которая называ­ется полити­кой одно­го источни­ка (Same-Origin Policy). SOP защища­ет конеч­ного поль­зовате­ля от того, что код в одном окне бра­узе­ра укра­дет дан­ные из дру­гого.

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

Все работа­ет очень прос­то, PostMessage пред­полага­ет два обя­затель­ных ком­понен­та:

• window.postMessage() — отправ­ляет сооб­щение;
• window.addEventListener(message, callback) — исполь­зует­ся для получе­ния и обра­бот­ки сооб­щения.

Один метод нуж­но зап­рашивать в окне, которое хочет отпра­вить дан­ные, дру­гой — в том, которое хочет получить эти дан­ные. Дру­гими сло­вами, это некое сог­лашение, которое поз­воля­ет обме­нять­ся толь­ко теми дан­ными, о которых окна пред­варитель­но догово­рились друг с дру­гом.

Burp Suite и DOM Invader

В Burp Suite есть встро­енный бра­узер с рас­ширени­ем DOM Invader. Оно поз­воля­ет авто­мати­зиро­вать некото­рые ата­ки и показы­вать содер­жимое сооб­щений, пересы­лаемых меж­ду окна­ми с помощью PostMessage.

Что­бы открыть бра­узер, надо запус­тить Burp, перей­ти в Proxy и нажать Open browser.

От­кро­ется обыч­ный Chromium, но с импорти­рован­ным SSL-сер­тифика­том от PortSwigger, вклю­чен­ным прок­си‑сер­вером, который сра­зу «из короб­ки» нап­равля­ет все зап­росы в Burp, и с рас­ширени­ем DOM Invader, которое может помочь экс­плу­ати­ровать XSS, Prototype Pollution и смот­реть содер­жимое пост‑мес­седжей.

Рас­ширение пре­дус­танов­лено, но может быть вык­лючено по умол­чанию. Что­бы вклю­чить, надо перей­ти в chrome://extensions/ и пос­тавить соот­ветс­тву­ющую галоч­ку.

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

Те­перь мож­но открыть сайт stevesouders.com/misc/test-postmessage.php (или любой ана­логич­ный), нажать на пер­вый тест и уви­деть, как рас­ширение залоги­рует отправ­ленное сооб­щение.

Ес­ли все так, как у меня на скри­не, мож­но перехо­дить к лабе.

Лаба: Stealing OAuth access tokens via a proxy page

• Ла­бора­тор­ная работа на сай­те PortSwigger

От­кры­ваем глав­ную сай­та, где встре­чаем мно­гообе­щающую кар­тинку.

По уже обка­тан­ному сце­нарию заходим в акка­унт wiener, став­ший нам род­ным.

От­кры­ваем HTTP History в Burp, находим Authorization Request, пересы­лаем его в Repeater и начина­ем экспе­римен­тировать.

Для начала попыта­емся про­вер­нуть тот же самый трюк, к которо­му мы при­бег­ли в прош­лой лабора­тории. Поп­робу­ем экс­плу­ати­ровать ста­рый доб­рый Open Redirect, который поз­волил нам ранее украсть токен адми­нис­тра­тора. Заменя­ем стан­дар­тный redirect_uri зна­комым уже пей­лоадом с Path Traversal и «ссыл­кой на пост», где вмес­то пос­та — google.com.

От­пра­вив зап­рос, видим, что редирект дей­стви­тель­но есть. Это пер­вичный приз­нак того, что мы можем исполь­зовать эту ссыл­ку, что­бы про­кинуть кас­томный URL.

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

А обыч­ный зап­рос со сто­рон­ним сай­том будет говорить о мис­матче. При­дет­ся ковырять сам сайт на наличие нового Open Redirect или какой‑либо дру­гой уяз­вимос­ти, которая при­вела бы нас к написа­нию рабоче­го экс­пло­ита.

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

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

На стра­нице есть сле­дующий код на JavaScript:

Раз­берем­ся, что он дела­ет. Сна­чала вызыва­ется вот такой метод:

Он озна­чает, что пос­ле заг­рузки стра­ницы нуж­но отпра­вить сооб­щение onload родитель­ско­му окну (если оно сущес­тву­ет) с текущим URL стра­ницы (window.location.href) в клю­че data.

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

Эта стро­ка пре­дот­вра­щает стан­дар­тное дей­ствие бра­узе­ра по отправ­ке фор­мы.

Здесь соз­дает­ся объ­ект FormData, который содер­жит дан­ные из фор­мы с иден­тифика­тором comment-form.

Соз­дает­ся объ­ект URLSearchParams, который содер­жит парамет­ры из хеш‑час­ти URL (всё пос­ле решет­ки).

Соз­дает­ся пус­той объ­ект o.

Эта стро­ка запол­няет объ­ект o дан­ными из фор­мы.

В объ­ект o добав­ляют­ся парамет­ры из хеш‑час­ти URL.

Этот метод отправ­ляет сооб­щение родитель­ско­му окну с типом oncomment и содер­жимым дан­ных из фор­мы, вмес­те с парамет­рами хеша.

И наконец, form.reset() сбра­сыва­ет фор­му, очи­щая все ее поля.

Ес­ли всё обоб­щить, то про­исхо­дит сле­дующее. На стра­ницу заг­ружа­ется iframe, внут­ри — поля для отправ­ки ком­мента­рия. Ког­да поль­зователь их запол­няет и нажима­ет Send Comment, в родитель­ское окно воз­вра­щает­ся содер­жимое фор­мы, а отту­да дан­ные отправ­ляют­ся на эндпо­инт send_form, который и пуб­лику­ет сам ком­мента­рий.

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

По­том «наверх» отправ­ляет­ся уже содер­жимое самого ком­мента­рия.

Эти же сооб­щения мож­но уви­деть в DOM Invader.

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

Как же исполь­зовать эту фор­му? Клю­чевое для нас — событие onload, при обра­бот­ке которо­го в родитель­ское окно воз­вра­щает­ся URL, вклю­чая ту часть, которая идет пос­ле зна­ка #. Кро­ме того, домен родитель­ско­го окна не про­веря­ется.

Как ты пом­нишь, OAuth-токен воз­вра­щает­ся тоже пос­ле зна­ка #, а это зна­чит, что если мы ука­жем в качес­тве redirect_uri ссыл­ку на эту фор­му, то в ито­ге смо­жем получить токен из пост‑мес­седжа в родитель­ском окне. В качес­тве родитель­ско­го окна будет выс­тупать наш экс­пло­ит‑сер­вер, где мы и перех­ватим токен.

Пе­рей­дем в Burp Repeater и заменим redirect_uri ссыл­кой на фор­му с ком­мента­рием, не забывая исполь­зовать Path Traversal из пре­дыду­щего задания (ина­че сер­вер не при­мет ссыл­ку).

От­кро­ем ссыл­ку и уви­дим цепоч­ку редирек­тов, которая при­водит нас на фор­му с отправ­кой ком­мента­рия, и OAuth-токеном в URL. Фор­ма берет URL и нап­равля­ет его в родитель­ское окно, которо­го пока что у нас нет.

Пе­рехо­дим к экс­пло­ит‑сер­веру и пишем код, который откры­вает наш прош­лый URL в iframe.

На­жима­ем на Store и стал­кива­емся с непонят­ной ошиб­кой.

Стал­кивал­ся с этой ошиб­кой не я один, и на форуме PortSwigger были све­жие темы, где люди жалова­лись на то же самое.

Как выяс­нилось, Chrome в новых вер­сиях по умол­чанию бло­киру­ет сто­рон­ние куки, и, что­бы прой­ти лабора­торию, при­дет­ся добавить домен экс­пло­ит‑сер­вера в исклю­чения бра­узе­ра. Для это­го перей­ди в раз­дел нас­тро­ек Privacy and security и вставь в Site allowed to use third-party cookies домен экс­пло­ит‑сер­вера.

Дол­жно получить­ся, как у меня на скрин­шоте.

Воз­вра­щаем­ся обратно к экс­пло­ит‑сер­веру.

До­бавим еще неболь­шой JavaScript-код, который прос­то соз­дает так называ­емый listener («слу­шатель»), цель которо­го — при­нять PostMessage от дочер­него окна и вывес­ти его содер­жимое в кон­соль.

Код — на скрин­шоте ниже.

Пос­мотрим, что получи­лось. Откры­ваем Exploit Server.

И видим, как в кон­соли отоб­ража­ется URL с нашим токеном. Теперь нам надо научить­ся кодиро­вать дан­ные (так как всё, что идет пос­ле решет­ки, не логиру­ется, и нам надо испра­вить это) и делать редирект на экс­пло­ит‑сер­вер, что­бы дан­ные осе­дали в access-логе, отку­да мы их смо­жем заб­рать (тот самый access-токен адми­нис­тра­тора).

Эти же дан­ные мож­но уви­деть в DOM Invader.

Те­перь меня­ем console.log на fetch.

Об­новля­ем код на экс­пло­ит‑сер­вере.

От­кры­ваем сайт и видим, как вмес­то того, что­бы сох­ранить сооб­щение в логах, из него извле­чен URL и отправ­лен пря­мо к нам на экс­пло­ит‑сер­вер, с исполь­зовани­ем URL-кодиро­вания.

Те­перь, если гля­нуть в логи, мож­но уви­деть там же эту ссыл­ку.

Нап­равля­ем адми­нис­тра­тора на нашу стра­ницу и смот­рим за новыми логами.

Ко­пиру­ем ссыл­ку, которая там появи­лась, и декоди­руем ее в Decoder.

Бе­рем токен и отправ­ляем на эндпо­инт /me.

А вот и API-ключ адми­нис­тра­тора! Лаба прой­дена.

Выводы

В этой статье мы поз­накоми­лись с тех­нологи­ей PostMessage и разоб­рали, как ком­биниро­вать раз­ные баги в OAuth, что­бы устра­ивать более прод­винутые ата­ки и повышать импакт.

Но не сто­ит оста­нав­ливать­ся на одном толь­ко OAuth. В зак­лючитель­ной статье из этой серии мы узна­ем о надс­трой­ке над ним, которая более стан­дарти­зиро­вана и приз­вана решить часть проб­лем, но по‑преж­нему не лишена уяз­вимос­тей.

Кро­ме того, мы сос­тавим чек‑лист для пен­теста и научим­ся авто­мати­зиро­вать поиск багов.