Уязвимости в OAuth. Глава из книги «Ловушка для багов. Полевое руководство по веб-хакингу»

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

На момент написа­ния у OAuth есть две вер­сии, 1.0a и 2.0, которые несов­мести­мы друг с дру­гом. По OAuth написа­ны целые кни­ги, но эта гла­ва фокуси­рует­ся на OAuth 2.0 и базовом рабочем про­цес­се OAuth.

О книге

Пе­ред тобой — 17-я гла­ва из кни­ги «Ловуш­ка для багов. Полевое руководс­тво по веб‑хакин­гу», которую мы пуб­лику­ем с раз­решения изда­тель­ства «Питер».

Эта кни­га поможет в совер­шенс­тво­вании скил­лов работы с вебом и рас­ска­зыва­ет о методо­логии этич­ного веб‑хакин­га. Чита­ется она отлично, слов­но детек­тивный рас­сказ. Каж­дая опи­сыва­емая уяз­вимость име­ет парамет­ры: слож­ность, ата­кован­ный URL, URL стра­ницы, где хакер опи­сал про­веден­ную ата­ку, дата подачи отче­та и сум­ма вып­лачен­ного хакеру воз­награж­дения. Сре­ди про­чего есть опи­сание удач­ного взло­ма PornHub.com.

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

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

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

Принцип работы OAuth

В про­цес­се аутен­тифика­ции на осно­ве OAuth учас­тву­ют три сто­роны:

• Вла­делец ресур­са — поль­зователь, пыта­ющий­ся вой­ти через OAuth.
• Сер­вер ресур­са — сто­рон­ний API-интерфейс, который аутен­тифици­рует вла­дель­ца ресур­са. Эту роль может играть любой сайт (Facebook, Google, LinkedIn и т. д.).
• Кли­ент — сто­рон­нее при­ложе­ние, которое посеща­ет/исполь­зует вла­делец ресур­са. Име­ет дос­туп к дан­ным сер­вера ресур­са.

При попыт­ке аутен­тифика­ции с помощью OAuth кли­ент зап­рашива­ет дос­туп к вашей информа­ции у сер­вера ресур­са (в дан­ном слу­чае у вас). Его может инте­ресо­вать пол­ный набор ваших дан­ных или их часть, огра­ничен­ная областя­ми видимос­ти. Нап­ример, поль­зовате­ли в Facebook име­ют такие области видимос­ти, как email, public_profile, user_friends и т. д. Если выдать кли­енту дос­туп толь­ко к email, он не смо­жет получить содер­жимое вашего про­филя, спи­сок дру­зей и т. п.

Про­цесс пер­вого вхо­да в кли­ент с исполь­зовани­ем Facebook в качес­тве демонс­тра­цион­ного сер­вера ресур­са начина­ется, ког­да вы откры­ваете стра­ницу кли­ента и нажима­ете кноп­ку Войти через Facebook. Кли­ент выпол­няет GET-зап­рос к конеч­ной точ­ке аутен­тифика­ции, которая час­то име­ет такой путь: https://www.<example>.com/oauth/facebook/. Shopify, к при­меру, исполь­зует для OAuth стра­ницу Google с URL-адре­сом https://<STORE>.myshopify.com/admin/auth/login?google_apps=1/.

В ответ на этот HTTP-зап­рос кли­ент перенап­равля­ет вас к сер­веру ресур­са, исполь­зуя код 302. URL-адрес стра­ницы перенап­равле­ния содер­жит сле­дующие парамет­ры, учас­тву­ющие в про­цес­се аутен­тифика­ции:

• client_id иден­тифици­рует кли­ент на сер­вере ресур­са уни­каль­ным зна­чени­ем.
• redirect_uri опре­деля­ет, куда сер­вер ресур­са дол­жен нап­равить бра­узер вла­дель­ца пос­ле его аутен­тифика­ции.
• response_type опре­деля­ет тип воз­вра­щаемо­го отве­та. Обыч­но это токен или код. В слу­чае воз­вра­щения токена поль­зователь сра­зу же получа­ет дос­туп к информа­ции на сер­вере ресур­са. Если вы получи­ли код, его нуж­но обме­нять на токен в ходе допол­нитель­ного эта­па OAuth.
• Па­раметр scope опре­деля­ет пра­ва дос­тупа, которые кли­ент зап­рашива­ет у сер­вера ресур­са. В ходе пер­вого зап­роса авто­риза­ции вла­дель­цу ресур­са дол­жно быть показа­но диало­говое окно, в котором он может прос­мотреть зап­рашива­емые области видимос­ти и дать свое сог­ласие.
• state — это слу­чай­ное зна­чение, пре­дот­вра­щающее под­делку меж­сай­товых зап­росов. Оно дол­жно при­сутс­тво­вать в HTTP-зап­росе к сер­веру ресур­са. Это зна­чение воз­вра­щает­ся кли­енту, что­бы зло­умыш­ленник не смог ини­цииро­вать про­цесс аутен­тифика­ции от име­ни дру­гого поль­зовате­ля.

URL-адрес, ини­циирующий про­цеду­ру OAuth с помощью Facebook, выг­лядит при­мер­но так:

По­лучив ответ с кодом перенап­равле­ния 302, бра­узер отправ­ляет сер­веру ресур­са GET-зап­рос. Вой­дя на сер­вер ресур­са, вы уви­дите диало­говое окно, с помощью которо­го мож­но одоб­рить области видимос­ти, зап­рашива­емые кли­ентом. На рис. 17.2 показа­но, как веб‑сайт Quora (кли­ент) зап­рашива­ет дос­туп к информа­ции у Facebook (сер­вера ресур­са) от име­ни вла­дель­ца ресур­са.

На­жатие кноп­ки Continue as John (Про­дол­жить как Джон) при­водит к одоб­рению зап­роса сай­та Quora на получе­ние дос­тупа к перечис­ленным областям видимос­ти, вклю­чая про­филь, спи­сок поль­зовате­лей, дату рож­дения, род­ной город вла­дель­ца ресур­са и про­чие све­дения. Ког­да вла­делец наж­мет кноп­ку, Facebook вер­нет HTTP-ответ с кодом 302, который перенап­равит бра­узер обратно к стра­нице с URL-адре­сом, ука­зан­ным в парамет­ре redirect_uri. Этот адрес так­же содер­жит токен и параметр state. Адрес перенап­равле­ния из Facebook в Quora может выг­лядеть так (изме­нено в целях демонс­тра­ции):

Сер­вер Facebook вер­нул токен access_token, с помощью которо­го кли­ент Quora мог сра­зу же получить дос­туп к информа­ции о вла­дель­це ресур­са. На этом учас­тие вла­дель­ца в про­цеду­ре OAuth завер­шено. Теперь кли­ент может нап­рямую обра­щать­ся к Facebook API за нуж­ной ему поль­зователь­ской информа­цией.

Вла­делец смо­жет даль­ше исполь­зовать кли­ент, не зная о его вза­имо­дей­ствии с API-интерфей­сом.

Но если бы вмес­то access_token сайт Facebook вер­нул код, кли­енту Quora приш­лось бы обме­нять его на токен, ина­че он бы не смог зап­рашивать информа­цию у сер­вера ресур­са. Для это­го кли­ент и сер­вер вза­имо­дей­ству­ют нап­рямую, без учас­тия бра­узе­ра вла­дель­ца. Что­бы получить токен, кли­ент сам выпол­няет HTTP-зап­рос к сер­веру ресур­са и переда­ет в URL-адре­се три парамет­ра: code (код дос­тупа) client_id и client_secret. Код дос­тупа — это зна­чение, которое сер­вер вер­нул через HTTP-перенап­равле­ние со ста­тусом 302. Параметр client_secret явля­ется кон­фиден­циаль­ным и дол­жен хра­нить­ся на сто­роне кли­ента. Он генери­рует­ся сер­вером ресур­са на эта­пе кон­фигура­ции при­ложе­ния и наз­начения client_id.

На­конец, получив от кли­ента зап­рос с парамет­рами client_secret, client_id и code, сер­вер про­веря­ет эти зна­чения и воз­вра­щает в ответ access_token. Пос­ле это­го кли­ент получа­ет воз­можность зап­рашивать у сер­вера информа­цию о вла­дель­це ресур­са, и про­цеду­ра OAuth счи­тает­ся завер­шенной. Обыч­но, если вы уже раз­решили сер­веру ресур­са пре­дос­тавлять вашу информа­цию, при сле­дующем вхо­де в кли­ент через Facebook про­цеду­ра OAuth выпол­няет­ся в фоновом режиме. Это вза­имо­дей­ствие мож­но будет наб­людать толь­ко в слу­чае монито­рин­га HTTP-зап­росов. Это поведе­ние по умол­чанию. Кли­ент может его изме­нить так, что­бы вла­делец ресур­са заново аутен­тифици­ровал­ся и одоб­рял области видимос­ти, но это боль­шая ред­кость.

То, нас­коль­ко серь­езной явля­ется уяз­вимость в OAuth, зависит от одоб­ренных областей видимос­ти, свя­зан­ных с токеном. В этом вы сами убе­дитесь на сле­дующих при­мерах.

Похищение OAuth-токенов на сайте Slack

• Слож­ность: низ­кая
• URL: slack.com/oauth/authorize/
• Ис­точник: hackerone.com/reports/2575/
• Да­та подачи отче­та: 1 мар­та 2013 года
• Вып­лачен­ное воз­награж­дение: 100 дол­ларов

Од­на из рас­простра­нен­ных уяз­вимос­тей в OAuth воз­ника­ет, ког­да раз­работ­чик неп­равиль­но нас­тра­ивает или срав­нива­ет допус­тимые парамет­ры redirect_uri, поз­воляя зло­умыш­ленни­кам похитить OAuth-токены. Пра­хар Пра­сад информи­ровал ком­панию Slack о том, что он может обой­ти огра­ниче­ния, ука­зан­ные в раз­решен­ном адре­се redirect_uri, за счет добав­ления к нему любых зна­чений. Ины­ми сло­вами, сайт Slack про­верял лишь начало парамет­ра redirect_uri. Если раз­работ­чик регис­три­ровал в Slack новое при­ложе­ние и добав­лял в белый спи­сок https://www.<example>.com, зло­умыш­ленник мог рас­ширить этот URL-адрес и выпол­нить перенап­равле­ние в неп­редви­ден­ное мес­то. Нап­ример, изме­нен­ный адрес вида redirect_uri=https://<attacker>.com откло­нял­ся, но поз­волял передать redirect_uri=https://www.<example>.com.mx.

Что­бы этим вос­поль­зовать­ся, зло­умыш­ленни­ку было дос­таточ­но соз­дать под­ходящий под­домен на сво­ем вре­донос­ном сай­те. Если жер­тва откры­вала заражен­ный URL-адрес, сер­вер Slack переда­вал OAuth-токен сай­ту зло­умыш­ленни­ка. Хакер мог ини­цииро­вать зап­рос от име­ни жер­твы, встро­ив во вре­донос­ную веб‑стра­ницу тег <img> вро­де такого:

Это поз­волило бы авто­мати­чес­ки сде­лать HTTP-зап­рос типа GET при отоб­ражении стра­ницы.

Выводы

Уяз­вимос­ти, свя­зан­ные с недос­таточ­но стро­гой про­вер­кой redirect_uri, явля­ются рас­простра­нен­ным при­мером неп­равиль­ной кон­фигура­ции OAuth. Иног­да это выз­вано тем, что в качес­тве допус­тимого зна­чения redirect_uri регис­три­рует­ся домен вида *.<example>.com. Иног­да при­чина в том, что сер­вер ресур­са не про­водит стро­гую про­вер­ку парамет­ра redirect_uri от начала и до кон­ца. При поис­ке уяз­вимос­тей в OAuth про­веряй­те любые парамет­ры, которые могут учас­тво­вать в перенап­равле­нии.

Прохождение аутентификации с паролем по умолчанию

• Слож­ность: низ­кая
• URL: flurry.com/auth/v1/account/
• Ис­точник: lightningsecurity.io/blog/password-not-provided/
• Да­та подачи отче­та: 30 июня 2017 года
• Вып­лачен­ное воз­награж­дение: не раз­гла­шает­ся

По­иск уяз­вимос­тей в любой реали­зации OAuth под­разуме­вает иссле­дова­ние всей про­цеду­ры аутен­тифика­ции, от начала и до кон­ца. Для это­го в том чис­ле необ­ходимо рас­познать HTTP-зап­росы, которые не явля­ются частью стан­дар­тно­го про­цес­са; их наличие час­то сиг­нализи­рует о том, что раз­работ­чик изме­нил механизм аутен­тифика­ции и, воз­можно, сде­лал его уяз­вимым. Джек Кей­бл стол­кнул­ся с подоб­ной ситу­ацией в работе с прог­раммой Bug Bounty от Yahoo, в которую вхо­дил ана­лити­чес­кий сайт Flurry.com.

Что­бы начать тес­тирова­ние, Кей­бл зарегис­три­ровал учет­ную запись на сай­те Flurry, исполь­зуя свой адрес элек­трон­ной поч­ты @yahoo.com и реали­зацию OAuth от Yahoo. Пос­ле того как Flurry и Yahoo сог­ласова­ли OAuth-токен, зак­лючитель­ный POST-зап­рос к сай­ту Flurry выг­лядел так:

Вни­мание Кей­бла прив­лек фраг­мент зап­роса "password":"not-provided". Вый­дя из сво­ей учет­ной записи, он открыл стра­ницу https://login.flurry.com/ и аутен­тифици­ровал­ся не через OAuth, а с помощью поч­тового адре­са и пароля not-provided. Это сра­бота­ло, и Кей­бл смог вой­ти в свою учет­ную запись.

Ког­да поль­зователь регис­три­ровал­ся на сай­те Flurry с помощью сво­ей учет­ной записи Yahoo и про­цеду­ры OAuth, сис­тема соз­давала для него отдель­ную кли­ент­скую учет­ную запись с паролем по умол­чанию not-provided. Кей­бл сооб­щил об уяз­вимос­ти, и проб­лема была устра­нена через пять часов.

Выводы

Нес­тандар­тные эта­пы OAuth час­то пло­хо скон­фигури­рова­ны и под­верже­ны уяз­вимос­тям, поэто­му зас­лужива­ют про­вер­ки.

Похищение токенов для входа на сайт Microsoft

• Слож­ность: высокая
• URL: login.microsoftonline.com
• Ис­точник: whitton.io/articles/obtaining-tokens-outlook-office-azure-account/
• Да­та подачи отче­та: 24 янва­ря 2016 года
• Вып­лачен­ное воз­награж­дение: 13 000 дол­ларов

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

Ком­пания Microsoft вла­деет мно­жес­твом про­ектов, поэто­му зап­росы для аутен­тифика­ции поль­зовате­лей на раз­ных сер­висах нап­равля­ются раз­ным доменам: login.live.com, login.microsoftonline.com или login.windows.net. Эти зап­росы воз­вра­щают поль­зовате­лям сес­сии. Нап­ример, в слу­чае с outlook.office.com про­цеду­ра выг­лядит так:

1. Поль­зователь заходит на сайт https://outlook.office.com.

2. Поль­зователь перенап­равля­ется к

   https://login.microsoftonline.com/login.srf?wa=wsignin1.0&rpsnv=4&wreply=https%3a%2f%2fbutlook.office.com%2fowa%2f&id=260563

3. В слу­чае успе­ха по адре­су внут­ри wreply выпол­няет­ся POST-зап­рос с парамет­ром t, который содер­жит токен для поль­зовате­ля.

При попыт­ке поменять wreply на любой дру­гой домен воз­никала ошиб­ка. Уит­тон поп­робовал переда­вать сим­волы с двой­ным кодиро­вани­ем, добав­ляя в конец URL-адре­са %252f, что­бы получить https%3a%2f%2foutlook.office.com%252f. В этом URL-адре­се спе­циаль­ные сим­волы : и / кодиру­ются как %3a и, соот­ветс­твен­но, %2f. Кро­ме того, в исходном адре­се сле­дует закоди­ровать знак про­цен­та (%), что­бы при двой­ном кодиро­вании он прев­ратил­ся в косую чер­ту %252f (кодиро­вание спе­циаль­ных сим­волов обсужда­лось в раз­деле «Раз­деление HTTP-отве­та в Twitter» на с. 77). Ког­да Уит­тон под­ста­вил вмес­то wreply получен­ный URL-адрес, при­ложе­ние вер­нуло ошиб­ку, сооб­щающую, что адрес https://outlook.office.com%f некор­ректен.

Вслед за этим Уит­тон добавил к домену @example.com и вмес­то ошиб­ки получил https://outlook.office.com%2f@example.com/?wa=wsignin1.0. Дело в том, что URL-адрес име­ет сле­дующую струк­туру:

Имя поль­зовате­ля и пароль учас­тву­ют в базовой HTTP-аутен­тифика­ции сай­та. Поэто­му пос­ле добав­ления @example.com домен для перенап­равле­ния боль­ше не выг­лядел как outlook.office.com. Вмес­то это­го поль­зовате­ля мож­но было перенап­равить к любому домену, который кон­тро­лиро­вал­ся зло­умыш­ленни­ком.

По сло­вам Уит­тона, при­чиной этой уяз­вимос­ти было то, что сайт Microsoft выпол­нял декоди­рова­ние и про­вер­ку URL-адре­са в два эта­па. На пер­вом эта­пе сайт про­верял, явля­ется ли домен­ное имя кор­рек­тным и соот­ветс­тву­ет ли оно струк­туре URL-адре­са. Адрес https://outlook.office.com%2f@example.com успешно про­ходил про­вер­ку, пос­коль­ку стро­ка outlook.office.com%2f вос­при­нима­лась как кор­рек­тное имя поль­зовате­ля.

На вто­ром эта­пе сайт рекур­сивно декоди­ровал URL-адрес. Стро­ка
https%3a%2f%2foutlook.office.com%252f@example.com прев­ращалась в https:// outlook.office.com/@example.com, то есть фраг­мент @example.com пос­ле косой чер­ты интер­пре­тиро­вал­ся как часть пути, а домен­ное имя выг­лядело как outlook.office.com.

Сайт Microsoft про­верял струк­туру URL-адре­са, декоди­ровал его и под­тверждал его при­сутс­твие в белом спис­ке. Но в качес­тве отве­та воз­вра­щал­ся адрес, декоди­рован­ный один раз. То есть при посеще­нии такого URL токен жер­твы отправ­лялся сай­ту example.com.

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

Выводы

В ходе иссле­дова­ния парамет­ров перенап­равле­ния в про­цеду­ре OAuth добавь­те к конеч­ному URI-адре­су @example.com и пос­мотри­те, как поведет себя при­ложе­ние. Это осо­бен­но акту­аль­но, если в про­цес­се аутен­тифика­ции исполь­зуют­ся закоди­рован­ные сим­волы, которые дол­жны быть декоди­рова­ны перед про­вер­кой вхож­дения URL-адре­са в белый спи­сок. Во вре­мя тес­тирова­ния обра­щай­те вни­мание на нез­начитель­ные изме­нения в поведе­нии сай­та.

Похищение официальных токенов доступа на сайте Facebook

• Слож­ность: высокая
• URL: facebook.com
• Ис­точник: philippeharewood.com/swiping-facebook-official-access-tokens/
• Да­та подачи отче­та: 29 фев­раля 2016 года
• Вып­лачен­ное воз­награж­дение: не раз­гла­шает­ся

При поис­ке уяз­вимос­тей обра­щай­те вни­мание на ресур­сы инте­ресу­юще­го вас при­ложе­ния, о которых раз­работ­чики мог­ли забыть. Филип­пе Хэй­рвуд пос­тавил перед собой цель: похитить токен поль­зовате­ля Facebook и получить дос­туп к его кон­фиден­циаль­ной информа­ции. Одна­ко ему не уда­лось най­ти никаких оши­бок в реали­зации OAuth на сай­те Facebook. Не отча­явшись, он поменял свой план и начал искать при­ложе­ние Facebook, которое мож­но зах­ватить как под­домен.

Он знал, что Facebook вла­деет при­ложе­ниями, которые авто­мати­чес­ки авто­ризу­ются с помощью OAuth, исполь­зуя учет­ные записи этой плат­формы. С их спис­ком мож­но было озна­комить­ся на стра­нице https://www.facebook.com/search/me/apps-used/.

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

В этом URL-адре­се иден­тифика­тор уяз­вимого при­ложе­ния обоз­начен в виде парамет­ра APP_ID, который пре­дос­тавлял дос­туп ко всем областям видимос­ти OAuth. Домен, вхо­див­ший в белый спи­сок, обоз­начен как REDIRECT_URI (Хэй­рвуд не уточ­нил, какое имен­но при­ложе­ние было неп­равиль­но скон­фигури­рова­но). Пос­коль­ку при­ложе­ние уже было авто­ризо­вано для каж­дой учет­ной записи Facebook, при щел­чке по этой ссыл­ке поль­зовате­лю не нуж­но было под­тверждать зап­рашива­емые области видимос­ти. Кро­ме того, вся про­цеду­ра OAuth выпол­нялась пос­редс­твом фоновых HTTP-зап­росов. Открыв этот URL-адрес для аутен­тифика­ции на сай­те Facebook, поль­зователь перенап­равлял­ся к стра­нице с подоб­ным адре­сом http://REDIRECT_URI/#token=сюда_добавлялся_токен/.

Пос­коль­ку Хэй­рвуд зарегис­три­ровал домен REDIRECT_URI, он мог записы­вать токены любых поль­зовате­лей, откры­вав­ших этот URL-адрес, что давало ему дос­туп к их учет­ным записям на сай­те Facebook. Кро­ме того, все офи­циаль­ные токены Facebook име­ли дос­туп к дру­гим при­ложе­ниям этой ком­пании, таким как Instagram. В ито­ге Хэй­рвуд мог аутен­тифици­ровать­ся на этих сай­тах от име­ни жер­твы.

Выводы

При поис­ке уяз­вимос­тей обра­щай­те вни­мание на ресур­сы, о которых мог­ли забыть вла­дель­цы сай­та. Иног­да это могут быть записи CNAME для под­доменов и зависи­мос­ти при­ложе­ний, такие как Ruby Gems, биб­лиоте­ки JavaScript и т. д. Перед началом тес­тирова­ния ставь­те перед собой чет­кую цель. В ходе иссле­дова­ния круп­ного при­ложе­ния это поз­волит не отвле­кать­ся на про­вер­ку его бес­числен­ных аспектов.

Итоги

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