Уязвимость с угоном токена Facebook

Согласно руководству Facebook для разработчиков (https://developers.facebook.com/docs/facebook-login/security), вам не нужно использовать access_token из какого-либо клиента Facebook SDK, не убедившись, что он создан специально для вашего приложения Facebook.

Мне интересно, какие уязвимости здесь. Почему меня должно волновать, какое приложение получило токен, если я могу использовать его для вызовов API и получения пользовательских данных через него?

Похищение токена

Чтобы понять, как это происходит, представьте собственное приложение iOS, которое хочет выполнять вызовы API, но вместо того, чтобы делать это напрямую, взаимодействует с сервером, принадлежащим тому же приложению, и передает этому серверу токен, сгенерированный с помощью iOS SDK. Затем сервер будет использовать токен для выполнения вызовов API.

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


facebook api security facebook-access-token
person Ed Gomoliako    schedule 21.01.2014    source источник
comment
Что ж, кто-то может передать токен для другого приложения, и тогда вы будете пытаться выполнить действие с другим приложением, что приведет к ошибкам или небезопасному поведению.   -  person Jimmy Kane    schedule 21.01.2014

Ответы (1)


arrow_upward
3
arrow_downward

Эти типы уязвимостей зависят от приложения — один из сценариев, который я могу придумать, таков:

Представьте, что вы используете аутентификацию Facebook как механизм SSO и создали приложение с веб-службой, которая возвращает некоторую личную информацию аутентифицированным пользователям. Этот веб-сервис называется /secretdocuments/download, который принимает токен доступа в качестве параметра.

Если веб-служба проверяет только то, что полученный токен доступа относится к пользователю, который находится в базе данных (путем вызова /me и последующего поиска в БД), то злоумышленник может:

  1. Создайте какое-нибудь другое приложение-приманку.
  2. Отправьте ссылку на это приложение одному из ваших пользователей и предложите ему установить его.
  3. Этот пользователь аутентифицируется с помощью приложения-приманки, и генерируется токен доступа. Приложение-приманка отправляет этот токен доступа злоумышленнику.
  4. Злоумышленник берет этот токен доступа и вызывает с его помощью ваш веб-сервис /secretdocuments/download.
  5. Ваш веб-сервис только проверяет, что токен доступа предназначен для пользователя, который находится в базе данных, и возвращает личную информацию злоумышленнику.

В этом сценарии ваш веб-сервис должен проверить, что предоставленный токен доступа был сгенерирован вашим приложением.

person madebydavid    schedule 21.01.2014