книги хакеры / журнал хакер / 175_Optimized

Пойманный пакет в Wireshark

WinRadius не отвечает на запросы

OAUTH? ЧТО ЭТО?

• Юзер — это пользователь провайдера, владеющий ресур-

OAuth — это открытый протокол авторизации, который позво-

сами (определенной информацией, графом друзей и так

ляет предоставить третьей стороне ограниченный доступ к за-

далее).

щищенным ресурсам пользователя без необходимости пере-

• Клиент — мобильное приложение/игра, вебсайт или дес-

давать ей логин и пароль. Например, ты разрабатываешь сайт

ктопный клиент — желает иметь доступ к ресурсам юзера.

и хочешь, чтобы пользователь имел возможность добавить свою

• Ключи (client credentials) — это постоянные аутентификаци-

персональную информацию из социальных сетей (личные дан-

онные токены клиента на провайдере. Состоят из client_id

ные, список друзей и так далее), например из сети «ВКонтак-

и client_secret.

те». Понятное дело, что сообщать данные своей учетки он тебе

• Токен (access_token) — это аутентификационные данные

не намерен. Вот тут-то в дело и вступает OAuth. В результате

юзера на провайдере, которые нужны для выполнения за-

пользователь логинится на «ВК», смотрит, к каким данным хочет

просов. Запрос выглядит в общем виде так: http://provider/

получить доступ твой сайт, и подтверждает (либо отклоняет) за-

me?access_token=123.

прос. А ты получаешь специальный токен, заменяющий собой

пару логин/пароль, с помощью которого можешь выполнять

Алгоритм работы OAuth 2 строится следующим образом.

разрешенные пользователем действия. Имеем: пользователю

Сначала клиент отсылает юзера на провайдер с целью получе-

не надо раскрывать свои логин/пароль, сторонний сайт полу-

Егор Хомяков

ния доступа к его ресурсам со следующими параметрами:

чает доступ (опять же с разрешения пользователя) к некоторым

@homakov

• redirect_uri — URL колбэка на домене клиента;

его данным. На первый взгляд все просто отлично. Но это толь-

• scope — список требуемых привилегий, например private_

ко на первый взгляд...

messages,user_profile,friends;

ДЕЙСТВУЮЩИЕ ЛИЦА

• client_id — ключ;

• state — случайное значение, которое провайдер вернет на-

Перед тем как продолжить, давай немного разберемся с тер-

зад.

минологией и принципом работы OAuth 2. В рамках статьи мы

будем оперировать следующими понятиями:

Юзер идет по ссылке к провайдеру, смотрит, что от него тре-

• Провайдер — это зачастую популярная социальная сеть

буют (параметр scope), и нажимает «Разрешить». В этом слу-

(Facebook, ВКонтакте, Twitter) с солидной базой пользова-

Андрей Лабунец

чае провайдер редиректит его назад на указанный redirect_uri

телей и данных о них.

@isciurus

на домене клиента со следующими параметрами:

• code — идентификатор юзера у провайдера, нужен клиенту,

Рис. 1. Отличие OpenID

1. Хакер получает код для своего аккаунта от провайдера по-

чтобы получить токен;

от OAuth

сле разрешения на доступ к ресурсам, но сам по ссылке

• state — то же значение, что было передано на начальный

не переходит.

URL. Используется для защиты от CSRF и для удобства.

2. Он заставляет пользователя перейти по ссылке с кодом,

принадлежащим хакерскому аккаунту (например, пишет

Код не представляет никакой ценности для юзера и его бра-

ему: «Васян, смотри, кто-то залил твои фотки URL»). Нужно

узера, так как с его помощью нельзя совершать запросы API,

произвести GET-запрос с браузера жертвы, например че-

и нужен он лишь для одной цели — получить токен клиенту,

рез картинку <img src="client/callback?code=123">.

не показывая его самому юзеру.

3. После чего клиент решит, что жертва присоединяет свой ак-

Для получения токена клиент производит POST-запрос

каунт провайдера, и получит по данному коду UID, равный

на /oauth/token, передав ключи (client_id, client_secret), code

UID хакера.

и redirect_uri, по которому был получен код, — таким образом

4. Тем самым начнет ассоциировать UID провайдера с теку-

провайдер уверен, что это нужный клиент, и по коду отдает

щим юзером, фейсбук хакера становится привязан к акка-

токен того самого юзера. Как понятно, ни юзер, ни User-Agent

унту жертвы, и дальше хакер может просто зайти через свой

и всякие клиентские скрипты (включая XSS) не увидели насто-

фейсбук, чтобы попасть прямо в аккаунт жертвы на клиенте.

ящий токен. Его знают только клиент и провайдер — в идеале.

Дальше токен используют для совершения API-запросов,

Защита: так как все редиректы в OAuth используют метод

когда он истекает, его можно рефрешить (для этого вместе с то-

GET, обычная CSRF-защита не обращает на них внимания. По-

кеном возвращается refresh_token).

этому придется сгенерировать случайный токен самим, сохра-

Что касается взаимодействия клиента с провайдером по пе-

Вся информация предо-

нить в сессии и отправить его в параметре state (он необяза-

редаче привилегий, то оно бывает двух типов — response_type:

ставлена исключительно

тельный, и это ошибка авторов стандарта). Провайдер вернет

code и token.

в ознакомительных

значение назад, и для проверки валидности нужно сравнить

Для code (Authorization Code Flow) провайдер возвращает

целях. Ни редакция,

значение state из колбэка и из сессии.

специальный код на колбэк (redirect_uri), по которому клиент

ни автор не несут от-

Session fixation on Client

делает запрос вместе с ключами, чтобы получить токен юзера.

ветственности за любой

Взаимодействие типа token, в свою очередь, более

возможный вред, при-

Если логин на клиенте уязвим CSRF, значит, есть возможность

уязвимо, так как идет передача самого токена напрямую

чиненный материалами

зафиксировать пользователя в хакерский аккаунт на клиенте

на redirect_uri на клиенте. Хотя он содержится в хеше (данные

данной статьи.

и присоединить аккаунт пользователя на провайдере к зафик-

после #) и не сливается в реферерах, он очень легко слива-

ется с помощью редиректов (смотри Fragment leak with 302

redirect далее).

На этом с теоретической частью закончим и перейдем не-

посредственно к рассмотрению уязвимостей. Надо сказать,

что они все взаимосвязаны, но я все же попытаюсь их распи-

сать по пунктам, ставя в них ссылки друг на друга.

ОШИБКИ РЕАЛИЗАЦИИ НА КЛИЕНТЕ

CSRF account hijacking

Рис. 2. Страница

Это самая распространенная ошибка, найденная на большин-

на провайдере, с помо-

стве веб-сайтов и библиотек (omniauth для rails, social auth

щью которой клиент за-

для django, facebook php sdk).

прашивает привилегии

Сценарий атаки выглядит следующим образом:

у юзера

сированному хакерскому аккаунту. То есть прицепить фейсбук

Рис. 3. На хабраха-

вить токен, — тогда точно большая часть клиентов будет уяз-

юзера к своему собственному аккаунту через его временную

бре можно вставлять

вима, либо провайдер дает удобную абстракцию (библиотеку)

фиксацию.

сторонние картинки,

каждому клиенту, где достаточно попросить токен через вызов

Правда, в большинстве случаев это не сработает, так

это скриншот того,

единственного метода и дождаться его в своем же колбэке.

как клиенты обычно разрешают привязать один провайдер-

как код ВКонтакте был

Безусловно, провайдерам по душе второй вариант. Итак, вроде

ский аккаунт к одному клиентскому, но если копии разрешены,

отправлен в реферере

бы простая задача по передаче токена заставляет провайдеров

то можно будет выполнять действия и влиять на социальные

на наш сервер

городить десятки килобайт уязвимого кода.

сети клиента, например спамить в его твиттере/фейсбуке.

Для доставки токена JS-приложению существует две по-

Защита: помним прописные истины веба, что каждое дей-

пулярных модели: модель прокси и модель контроллера. В пер-

ствие должно быть защищено CSRF-токеном, даже если оно

вом случае приложение выполняется внутри фрейма провай-

не несет в себе никакой видимой опасности.

дера, а во втором — нет (то есть клиентское приложение — это

ОШИБКИ РЕАЛИЗАЦИИ СЕРВЕРНОЙ

просто сайт, открытый в новой вкладке).

Модель с прокси предполагает создание специального

СТОРОНЫ НА ПРОВАЙДЕРЕ

фрейма внутри клиентского окна, в котором и открывается

Session fixation on Provider

URL для запроса токена. Только в качестве redirect_uri задается

специальный провайдерский прокси, куда возвращается токен

Очень многие сайты не проверяют CSRF-токен на логине и/или

после редиректа. Грязная работа по кросс-доменной переда-

логауте, что считается негрубой ошибкой. Да и правда, если

че токенов приложениям возлагается на JavaScript-код внутри

жертва увидит себя залогиненной на фейсбуке под чужим акка-

этого прокси-фрейма. Прокси-фреймами пользуются, напри-

унтом —ничего ужасного не случится. Но дело в том, что OAuth-

мер, фейсбук (Facebook Javascript SDK) и гугл (Google APIs

клиент всецело полагается на тот код, который ему вернет

Client Library for JavaScript).

фейсбук, а фейсбук вернет код того юзера, который в данный

Модель с контроллером во всех смыслах больше похо-

момент в нем залогинен.

жа на работу операционной системы: в качестве ядра здесь

Отсутствие проверки redirect_uri

выступает провайдерский надфрейм, в котором, подобно

syscall’ам, можно делать вызовы. Например, передав наверх

при обмене кода на токен

через postMessage строку определенного вида, приложение

Такая уязвимость была у ВКонтакте. Суть заключается в ис-

может попросить у провайдера токен для доступа к пользо-

пользовании в качестве redirect_uri такого раздела сайта, кото-

вательским данным (провайдер сам отрисует диалог автори-

рый каким-либо образом сливает код хакеру, например через

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

реферер или через open redirect.

либо через тот же postMessage, либо, если у тебя старый бра-

Хакер просто использует тот же код по правильному колбэ-

узер, через Flash. Именно так и работают canvas-приложения

ку, и клиент начинает верить, что это юзер. Полукостыльной за-

на фейсбуке. Главное отличие этой модели в том, что токен

щитой будет проверка redirect_uri уже в процессе обмена кода

запрашивает сам скрипт провайдера с помощью XHR, без от-

на токен, и если они не совпали, то это попытка взлома.

крытия новых окон и всей этой канители с редиректами: в са-

Реальной же защитой будет хранение redirect_uri в настрой-

мом деле, зачем редиректы и окна, если теперь границы до-

ках клиента, а не передача его параметром в процессе автори-

мена не нарушаются?

зации. «Гибкий» redirect_uri — это, пожалуй, 95% всех проблем,

В обеих моделях скрывается множество возможностей

связанных с OAuth, и они есть на фейсбуке и ВКонтакте.

для атак: суть главной из них — заставить прокси или контрол-

Таким образом, код будет выслан атакующему на левый

лер передать токен на чужой домен. И если в обычной реализа-

redirect_uri, и он сможет использовать его уже по правильному

ции OAuth тяжело ошибиться так, чтобы редирект мог вернуть

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

токен на домен атакующего, то в случае клиентского кода про-

ОШИБКИ РЕАЛИЗАЦИИ КЛИЕНТСКОЙ

верка соответствия доменов не такая уж тривиальная задача.

Кроме того, в реализации контроллера очень часто обработ-

СТОРОНЫ НА ПРОВАЙДЕРЕ

чик асинхронных запросов — это просто вызов eval(), а значит,

Важная и особенно интересная часть протоколов авторизации,

можно пойти дальше и атаковать контроллер вплоть до меж-

разработанных в рамках OAuth, — предоставляемый провайде-

сайтового скриптинга. В следующих статьях мы покажем не-

ром клиентский JavaScript-код, или JavaScript SDK. Казалось

сколько интересных уязвимостей в клиентском коде фейсбука

бы, RFC-документ описывает единственный нужный путь пере-

и гугла, приводящие как к угону токенов, так и к выполнению

дачи как токена, так и кода — серию редиректов. Откуда у мно-

кода (XSS).

гих провайдеров (например, Facebook, Google) может вообще

ОШИБКИ В СТАНДАРТАХ:

появиться необходимость добавлять объемный клиентский код

и как следствие — еще одно направление для атаки?

FRAGMENT LEAK WITH 302 REDIRECT

Если взглянуть с точки зрения JavaScript-приложения на ме-

Эран Хаммер (Eran

Для токен-взаимодействия токен передается на redirect_

ханизм получения токена по стандарту, то стандарт, естествен-

Hammer) вычеркнул себя

uri через hash-параметр, например http://site.com/

но, не говорит, что же делать дальше, когда токен оказался

из авторов стандарта

callback#access_token=123. Но у фрагмента есть такая инте-

в хеше адресной строки какого-то окна. Либо каждый клиент

и написал громкий пост

ресная особенность (я бы назвал ее уязвимостью, которую

пишет свой собственный код, чтобы распарсить URL и доста-

с критикой: bit.ly/OIU31c

никто не хочет исправлять) — при 302-м редиректе фрагмент

Facebook Connect был уязвим для классической Replay attack —

после одного использования кода он мог применяться для ау-

тентификации в течение следующих 80 минут. Реплай-атака

в чистом виде, а значит, чтобы увести аккаунт, нам нужно добыть

авторизационный код, например через логи, MITM, историю

браузера или другой способ.

Рис. 4. Админка

•

cut_me — нагрузка-пустышка, которая и содержит

Допустим, на сайте-клиенте найден XSS — примерно та-

клиента на провайде-

псевдоXSS, заставляющий хром заблокировать страницу.

кой скрипт вытаскивает код для правильного redirect_uri через

ре — можно настроить

В нашем случае это

document.referrer.

базовый домен и полу-

<script>var bigPipe = new (require('BigPipe'))

<iframe src="https://www.facebook.com/dialog/

чить свои ключи

({"lid":0,"forceFinish":true});</script>'

permissions.request?app_id=159618457465836&display=

page&next=http://magru.net/users/auth/facebook/

•

target_app_id — это client_id, токен которого мы хотим

callback&response_type=code" name="refcontainer"

украсть. Поэтому возьмем популярные приложения, токены

onload="alert(refcontainer.document.referrer)">

которых мы хотим слить.

</iframe>

FACEBOOK + OAUTH 2 + CHROME XSS AUDITOR

Эксплуатация:

1.

Открываем кучу окон с пробными client_id популярных при-

Напоследок хочу поделиться любопытной цепочкой уязви-

ложений (в хроме разрешено до 25 окон).

мостей, за которую мы с Андреем (@isciurus) получили 5000

2.

Если данное приложение уже было авторизовано, то его

долларов от фейсбука. Сначала объясню суть XSS Auditor

редиректит на FB_PATH#...signed_request=SR&access_

referrer leak.

token=TOKEN&state=PAYLOAD.

Задача XSS Auditor в хроме — детектить наличие каждого

3.

Здесь фейсбук копирует значение хеша в путь и ре-

JS-кода на странице в нагрузке (payload), то есть своеобразная

директит

на

FB_PATH/...?signed_request=SR&access_

защита от активных XSS. Он просто ищет совпадение скрипта

token=TOKEN&state=PAYLOAD.

в GET-, POST-параметрах и в location.hash. Логично предполо-

4.

Сервер отвечает HTML-страницей и хедером X-XSS-

жить, что если подкинуть пустышку — параметр, содержащий

Protection: '1; mode=block'. Кстати, URL содержит наш

код, который уже есть на этой странице, то аудитор найдет со-

payload, который также содержится на странице, — поэтому

впадение. Кстати, есть три режима X-XSS-Protection хедера

хром блокирует и редиректит на about:blank.

для управления аудитором хрома: 0 (выключить), 1 (включить,

5.

Наш парент теперь имеет доступ к этому окну, так

не запускать скрипты), 1;mode=block (включить, блокировать

как about:blank наследует наш ориджин, мы заходим и пар-

страницу).

сим access_token=TOKEN из playground.document.referrer

Фейсбук отсылал X-XSS-Protection: 1;mode=block. Уязви-

и закрываем playground.

мость заключалась в том, что после блокирования страницы

ЗАКЛЮЧЕНИЕ

браузер делал редирект на about:blank, который, в свою оче-

редь, наследует ориджин страницы парента и тем самым дает

Важно понимать, что OAuth не протокол, а лишь фреймворк,

доступ к адресу заблокированной страницы через playground.

на основе которого провайдеры строят свои API. В этом кро-

document.referrer (который может содержать приватную ин-

ется серьезная проблема совместимости — разработчики

формацию).

не могут создать единый интерфейс для любого провайде-

Помимо этого, существовал такой FB_PATH, содержащий JS

ра, к сожалению. За это OAuth и получает массу критики,

hashbang (трюк по управлению URL без перезагрузки, исполь-

что он «новый» Java/XML/PHP (то есть некая неудобная, но по-

зующий location.hash), который копировал значение после #

пулярная технология). При этом он пытается оставаться удоб-

в путь, тем самым раскрывая его в реферерах и отсылая на сер-

ным, игнорируя MITM и шифрование и полностью полагаясь

вер. Исходя из всего сказанного, украсть access_token произ-

на HTTPS-соединение. Да, он объективно удобней и понятней

вольного клиента можно при помощи следующего URL:

для разработчика, чем OAuth1, но он слишком абстрактен,

http://www.facebook.com/dialog/oauth?client_id=" +

и многие важные (в плане безопасности) моменты остаются

на усмотрение провайдера.

target_app_id + "&response_type=token&display=

ОAuth используют мно-

Например, Facebook до сих пор не исправил гибкий redirect_

none&domain=facebook.com&origin=1&redirect_uri=

гие крупные социальные

uri и CSRF на логине, так как, по их словам, это несерьезные

http%3A%2F%2Ffacebook.com%2F%23%2521%2Fconnect

сети: Reddit, Amazon,

угрозы. Все это очень даже смешно, я помню как минимум

%2Fxd_arbiter%23%21%2Ffind-friends%2Fbrowser%3Fc

deviantART, Yandex,

пять простейших уязвимостей, суть которых была в подмене

b%3Df3d2e47528%26origin%3Dhttp%253A%252F%252F

Facebook, Zendesk,

redirect_uri/response_type и паре редиректов, которые приводи-

developers.facebook.com%252Ff3ee4a8818%26domain%3D

VK, PayPal, Microsoft,

ли к угону токенов. По баунти-программам они отдали больше

facebook.com%26relation%3Dparent%26state%3D"+

Google, GitHub,

30 килобаксов вместо того, чтобы исправить очевидно кривую

cut_me+"&sdk=joey

Foursquare и другие.

архитектуру их реализации. Победителей не судят?