Вход через Facebook

Безопасность входа

Такие функции, как маркеры доступа и разрешения, делают вход через Facebook надежным и безопасным инструментом для людей и приложений. Однако в приложениях при этом необходимо реализовать дополнительные меры безопасности.

Видео

Джонатан Гросс и Брент Дорман на конференции F8 2015 рассказали о способах повышения безопасности при интеграции входа через Facebook.

Проверка безопасности

Ниже перечислены меры безопасности, которые необходимо реализовать во всех приложениях, где используется вход через Facebook. Их можно дополнить другими функциями, чтобы обеспечить максимальную защиту приложения. Без обеспечения должных мер безопасности люди могут потерять доверие к вашему приложению и перестать пользоваться им.

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

Используйте секрет приложения в качестве подписи во всех вызовах API Graph, отправляемых с сервера на сервер.

В клиентах пользуйтесь уникальными краткосрочными маркерами.

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

Используйте с диалогом входа параметр state.

По возможности пользуйтесь нашими официальными SDK.

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

Используйте протокол HTTPS.

Секрет приложения

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

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

Для обеспечения безопасности мы рекомендуем использовать маркеры доступа приложения только непосредственно на серверах приложения. Нативным приложениям рекомендуется обмениваться данными с вашим сервером, который в свою очередь должен отправлять запросы API к Facebook с использованием маркера доступа приложения. Если в дополнительных настройках панели приложений установлен тип приложения Native/Desktop, мы предполагаем, что ваше нативное приложение содержит секрет или маркер доступа в двоичном коде. В этом случае обработка вызовов, подписанных маркером доступа приложения, не выполняется. При этом API работает так, как если бы маркер доступа не предоставлялся.

Безопасные вызовы с сервера с параметром appsecret_proof

Чтобы приложение было менее уязвимым для вредоносного ПО и спама, в подписи к вызовам API Facebook, передаваемым с сервера на сервер, должен использоваться параметр appsecret_proof. Проверочный код секрета приложения — это код маркера доступа, хэшированный по алгоритму SHA256, где ключом является секрет приложения. Секрет приложения можно найти в Панели приложений, выбрав Настройки > Основное.

Генерация проверочного кода

Ниже приведен пример вызова на языке PHP:

$appsecret_proof= hash_hmac('sha256', $access_token.'|'.time(), $app_secret);

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

Добавление проверочного кода

Результат добавляется в виде параметра appsecret_proof, где appsecret_time имеет значение метки времени, которая использовалась при хэшировании секрета приложения в каждом вызове:

curl \
  -F 'access_token=ACCESS-TOKEN' \
  -F 'appsecret_proof=APP-SECRET-PROOF' \
  -F 'appsecret_time=APP-SECRET-TIME' \
  -F 'batch=[{"method":"GET", "relative_url":"me"},{"method":"GET", "relative_url":"me/accounts"}]' \
  https://graph.facebook.com

Проверочный код на базе секрета приложения с меткой времени действует 5 минут, поэтому при выполнении каждого вызова API Graph рекомендуется сразу генерировать новый проверочный код.

Требование проверочного кода

В Панели приложений перейдите в раздел Настройки > Дополнительно > Безопасность и включите параметр Требовать секрет приложения. Если эта функция включена, Facebook будет принимать только вызовы API, содержащие параметр appsecret_proof.

Безопасные вызовы с клиента с использованием краткосрочных маркеров и кода

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

Перехват маркеров

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

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

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

Если вы не используете Facebook SDK, регулярно проверяйте, действителен ли маркер доступа. Хотя маркеры доступа имеют определенный срок действия, он может истекать преждевременно из соображений безопасности. Если в приложении не используется Facebook SDK, крайне важно вручную реализовать регулярную проверку действительности маркеров (по крайней мере раз в день). Так вы избежите использования маркеров с истекшим сроком действия.

Параметр state

Если у вас на сайте используется диалог входа через Facebook, параметр state представляет собой уникальную строку, которая защищает приложение от подделки межсайтовых запросов.

Включение строгого режима

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

Прежде чем включать строгий режим в панели приложений, убедитесь, что ваш нынешний трафик перенаправления ещё работает. Для этого выполните следующие действия в настройках входа через Facebook:

  • Для приложений с URI динамического перенаправления используйте параметр state, чтобы передать динамическую информацию обратно на ограниченное количество URI перенаправления. Затем добавьте каждый из этих URI перенаправления в список действительных URI для перенаправления OAuth.

  • Для приложений с ограниченным количеством URI перенаправления каждый такой URI нужно добавить в список действительных URI для перенаправления OAuth.

  • В приложениях, использующих только Facebook SDK for JavaScript, трафик перенаправления уже защищен. Дополнительные действия не требуются.

После выполнения этих действий включите строгий режим.

Как работает строгий режим?

Строгий режим требует, чтобы URI точно соответствовали списку действительных URI для перенаправления OAuth, что предотвращает перехват URI переадресации. Например, если в списке есть адрес www.example.com, в строгом режиме не будет выполняться перенаправление по адресу www.example.com/token. Кроме того, запрещаются все дополнительные параметры запроса, которых нет в списке действительных URI для перенаправления OAuth.

Использование протокола HTTPS

Используйте вместо HTTP протокол HTTPS, так как он обеспечивает шифрование. HTTPS гарантирует конфиденциальность данных при передаче и предотвращает несанкционированный доступ к ним. Кроме того, этот протокол не позволяет подделать данные при передаче (например, добавить в них рекламу или вредоносный код).

С 6 октября 2018 г. все приложения должны использовать протокол HTTPS.

Активация SDK for JavaScript для входа через Facebook

Укажите, что вы используете SDK for JavaScript для входа, активировав переключатель Вход с помощью SDK for JavaScript. Затем добавьте домен страницы, на которой установлен SDK, в список Разрешенные домены SDK for JavaScript. Так маркеры доступа будут возвращаться обратным вызовам только на авторизованных доменах. Для аутентификации с помощью SDK for JavaScript поддерживаются только страницы, адрес которых начинается с https.

Если вы интегрировали SDK for JavaScript до 10 августа 2021 года, этот список заполняется значениями в соответствии с текущим использованием. Дополнительные действия не требуются.

Если вы выполнили интеграцию после 10 августа 2021 года, в этот список нужно добавить значения.

Если в поле домена SDK for JavaScript вашего приложения указаны URL, которые начинаются с *., замените их абсолютными URL домена, чтобы обеспечить дополнительную защиту.

Принципы проверки URI перенаправления

Когда злоумышленник добавляет в запрос на вход несанкционированный параметр redirect_uri, происходит открытое перенаправление. Оно может привести к потенциальной утечке конфиденциальной информации, например утечке маркера доступа через строку запроса или фрагмента URI перенаправления.

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

Браузеры в приложении и SDK for JavaScript

Как правило, для выполнения входа SDK for JavaScript использует всплывающие уведомления и обратные вызовы. Если браузер в приложении блокирует всплывающие уведомления, выполнить вход не удастся. В таких случаях SDK автоматически попытается выполнить перенаправление с маркером доступа на страницу, которая его вызвала. SDK удастся выполнить безопасное перенаправление, только если в поле "Действительные URI перенаправления для OAuth" указан полный URI страницы.

Если для вашего веб-приложения важны сценарии с использованием браузера в приложении, добавьте домен страницы входа в список разрешенных доменов и внесите полный URI (в том числе путь и параметры запроса) в список "Действительные URI перенаправления для OAuth". Если у вашего приложения множество вариантов URI входа, можно вручную указать параметр fallback_redirect_uri для вызова FB.login(). В этом случае вам потребуется добавить в список "Действительные URI перенаправления для OAuth" только эти данные.

Ограничение доступа к настройкам приложения Facebook

Включите и (или) отключите все неиспользуемые процессы аутентификации, чтобы свести к минимуму уязвимость приложения.

  • Используйте в клиентах краткосрочные маркеры доступа, созданные с помощью кода, а не маркеры, сгенерированные клиентом или предоставленные сервером маркеры доступа длительного действия. При использовании краткосрочных маркеров доступа, сгенерированных с помощью кода, сервер приложения обменивает код на маркер. Это гораздо безопаснее, чем получение маркера в браузере. Из соображений безопасности рекомендуется везде использовать маркеры, полученные в обмен на код (если это возможно). Тогда вредоносное ПО на компьютере пользователя не сможет получить маркер доступа и использовать его в ненадлежащих целях. Подробнее см. в нашей документации по маркерам доступа.

  • Отключите механизм авторизации Client OAuth Login, если ваше приложение его не использует. Client OAuth Login — это глобальный переключатель, позволяющий включать и отключать маркеры клиента OAuth. Если приложение не использует клиентские процессы OAuth, в том числе SDK для входа через Facebook, их следует отключить. Однако не забывайте, что при отключенной функции Client OAuth Login нельзя запросить разрешения для маркера доступа. Эта настройка находится на панели приложений в разделе Продукты > Вход через Facebook > Настройки.

  • Отключите веб-процессы OAuth или задайте список разрешенных URL для перенаправления. Настройки веб-авторизации OAuth позволяют любому маркеру клиента OAuth, использующему веб-диалог входа через Facebook, возвращать маркеры вашему сайту. Эта настройка доступна в разделе панели приложений Продукты > Вход через Facebook > Настройки. Отключите ее, если вы не разрабатываете пользовательский веб-процесс входа и не используете вход через Facebook из SDK в Интернете.

  • Используйте протокол HTTPS. Для этой настройки необходимо использовать протокол HTTPS для перенаправления OAuth, а все вызовы SDK Facebook for JavaScript, возвращающие маркер доступа или требующие его, должны выполняться только со страниц с включенным HTTPS. Эта настройка по умолчанию включена для всех приложений, созданных начиная с марта 2018 г. Кроме того, к 6 октября 2018 г. необходимо перенастроить все существующие приложения так, чтобы они использовали только URL HTTPS. Большинство популярных облачных платформ для хостинга приложений позволяет бесплатно и автоматически настраивать сертификаты TLS для приложений. Если вы разместили приложение на своем хостинге или ваша платформа хостинга не предлагает использовать HTTPS по умолчанию, вы можете получить для своих доменов бесплатный сертификат в службе Let's Encrypt.

  • Отключите встроенную в браузер авторизацию OAuth, если приложение ее не использует. Некоторые классические и мобильные нативные приложения используют для аутентификации пользователей клиентский процесс OAuth из встроенного веб-представления. Если ваше приложение этого не делает, отключите эту настройку на панели приложений в разделе Продукты > Вход через Facebook > Настройки.

  • Отключите процессы единого входа для мобильных устройств, если приложение их не использует. Если приложение не использует службу входа iOS или Android, отключите настройку "Единый вход" в разделах iOS и Android меню Настройки > Основное.

В панели приложений есть несколько дополнительных настроек, которые позволяют разработчикам защитить приложение от угроз безопасности:

  • Основное > Секрет приложения — здесь можно сбросить секрет приложения, если он был взломан.
  • Основное > Домены приложений — здесь можно ограничить доступ к доменам и поддоменам, которые можно использовать для входа через Facebook от имени приложения.
  • Дополнительно > Тип приложения — создавая нативное приложение для мобильных устройств или ПК с секретом приложения, установите для этого параметра значение Native/Desktop, чтобы предотвратить декомпиляцию приложения и защитить секрет от взлома.
  • Дополнительно > Разрешенный список IP-адресов сервера — список IP-адресов, с которых можно отправлять вызовы API Graph, содержащие секрет приложения. Вызовы API Graph, содержащие секрет приложения, но отправленные с других IP-адресов, будут игнорироваться. Эта настройка не распространяется на вызовы, использующие маркеры доступа пользователя.
  • Дополнительно > Обновить разрешенный список IP-адресов в настройках — изменять настройки приложения можно будет только с IP-адресов, добавленных в этот список. Будьте осторожны с этой настройкой при использовании широкополосного доступа для домашних абонентов. Если ваш IP-адрес изменится, вы больше не сможете изменять настройки приложения.
  • Дополнительно > Электронный адрес для уведомлений об изменениях — если в панели приложений изменяется хотя бы одна настройка, на указанный адрес отправляется уведомление.
  • Дополнительно > Защита публикации URL — приложение не сможет публиковать URL, которые не указывают на принадлежащий ему домен. Эта настройка не всегда полезна, особенно если вы знаете, что приложение будет публиковать ссылки на другие сайты.