Защита мобильных приложений¶

SmartBot Protection защищает нативные приложения iOS и Android с помощью проверки характеристик устройства и токена доступа. Для подключения защиты необходимо реализовать сбор характеристик, взаимодействие с программным интерфейсом и обработку результатов проверки в коде мобильного приложения.

Модель защиты¶

Защита мобильных приложений использует тот же механизм, что и защита веб-ресурсов и программных интерфейсов. Клиент подтверждает свою легитимность, получает токен и передаёт его при последующих запросах. Запрос без действительного токена блокируется на стороне ноды.

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

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

Легитимность клиента определяется по отпечатку устройства и состоянию его окружения, а не по строке User-Agent.

Разграничение ответственности¶

При подключении защиты необходимо учитывать, какие компоненты входят в состав SmartBot Protection, а какие реализуются на стороне заказчика.

На стороне SmartBot Protection:

Программный интерфейс проверки мобильных клиентов.
Выдача, проверка, продление и отзыв токенов.
Проверка строки идентификации клиента и отпечатка TLS-соединения на стороне сервера.
Оценка полученных от приложения сигналов по настраиваемым весам и пороговому значению.
Блокировка запросов, не прошедших проверку.
Схема защиты передаваемых данных.
Централизованная настройка состава сигналов, их весов, порога блокировки, срока жизни токена и интервала анализа без обновления приложения.

На стороне заказчика:

Реализация сбора характеристик устройства и признаков окружения в коде приложения.
Вычисление отпечатка устройства из собранных характеристик.
Встраивание вызовов программного интерфейса в сетевой слой приложения.
Хранение токена и его передача с запросами к защищаемым ресурсам.
Обработка ответов о блокировке и повтор цикла проверки.
Реализация схемы шифрования запросов на стороне клиента.
Защита приложения от анализа и модификации.

Состав признаков окружения приложение передаёт самостоятельно. Достоверность этих сведений зависит от защищённости приложения от анализа и изменения.

Обфускация кода, контроль целостности сборки и фиксация доверенных сертификатов реализуются средствами заказчика и не входят в поставку SmartBot Protection.

Серверные проверки не зависят от состояния приложения и выполняются независимо от его защищённости. К ним относятся проверка строки идентификации клиента, отпечатка TLS-соединения, срока действия и соответствия токена клиенту.

Порядок взаимодействия¶

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

Адрес служебного запроса формируется из адреса защищаемого ресурса заменой пути.

Например, если запрос к https://example.ru:8443/get/my/ip вернул признак блокировки, инициализация выполняется по адресу:

https://example.ru:8443/v1/antibot/m/init

Дополнительные сетевые правила и исключения в политиках безопасности приложения не требуются.

Обнаружение необходимости проверки¶

Приложение отслеживает ответы сервера.

Ответ с кодом 403 и заголовком X-Antibot-Response означает, что действующий токен отсутствует или недействителен.

При получении такого ответа необходимо:

Удалить сохранённый токен.
Запустить цикл проверки.
Приостановить остальные запросы до завершения проверки.

Инициализация¶

Метод init возвращает параметры сеанса:

Интервал последующего анализа.
Идентификатор ключа.
Открытый ключ для защиты передаваемых данных.

Регистрация¶

Метод register передаёт отпечаток устройства, исходные данные для его проверки и результаты проверок окружения.

При успешной проверке возвращается токен.

Ответ с кодом 403 означает, что клиент отклонён по результатам серверных проверок.

Повтор исходного запроса¶

После получения токена приложение повторяет исходный запрос с полученным токеном.

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

Периодический анализ¶

С интервалом, полученным при инициализации, приложение вызывает метод analyze.

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

Контракт программного интерфейса¶

Запросы методов register и analyze передаются в зашифрованном виде.

Симметричный ключ шифруется открытым ключом, полученным при инициализации. Идентификатор ключа передаётся вместе с данными.

Инициализация¶

GET /v1/antibot/m/init

Запрос выполняется без тела.

Успешный ответ возвращается с кодом 200 и типом содержимого application/json:

{
  "analyze_time": 30,
  "kid": "key_id",
  "key": "-----BEGIN PUBLIC KEY-----…"
}

Параметры ответа:

Параметр	Назначение
`analyze_time`	Интервал вызова анализа, секунд
`kid`	Идентификатор ключа
`key`	Открытый ключ для защиты симметричного ключа

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

Регистрация¶

POST /v1/antibot/m/register

Тип содержимого запроса – application/json.

Пример тела запроса:

{
  "fp": "fingerprint",
  "data": {},
  "signals_true": [],
  "signals_false": []
}

Параметры запроса:

Параметр	Назначение
`fp`	Отпечаток устройства
`data`	Объект с параметрами, из которых сформирован отпечаток, включая нестабильные характеристики для проверки корректности отпечатка на стороне сервера
`signals_true`	Список сработавших признаков
`signals_false`	Список пройденных проверок

Успешный ответ возвращается с кодом 200:

{
  "result": "ok",
  "token": {
    "name": "cookie_name",
    "value": "token"
  }
}

Возможные коды ответа:

200 – успешная регистрация.
403 – клиент отклонён по результатам проверки строки идентификации или отпечатка TLS-соединения.
500 – ошибка на стороне сервера.

Анализ¶

POST /v1/antibot/m/analyze

Тело запроса совпадает по составу с запросом регистрации и дополнительно содержит поле events, зарезервированное для передачи поведенческих характеристик.

Успешный ответ возвращается с кодом 200. Поле token присутствует, если токен был обновлён.

Пример ответа:

{
  "result": "ok",
  "token": {
    "name": "cookie_name",
    "value": "abc123..."
  }
}

Ответ с кодом 500 означает ошибку на стороне сервера.

Настройка на стороне ноды¶

Мобильный контур включается и настраивается в конфигурации SmartBot Protection независимо от веб-контура.

Пример конфигурации:

{
  "mobile": {
    "enabled": true,
    "token": {
      "ttl": 300
    },
    "signals": "/var/antibot/mobile_signals",
    "analyzejs": {
      "interval": 150
    },
    "registration": {
      "bad_score": 1
    }
  }
}

Основные параметры:

Параметр	Назначение
`mobile.enabled`	Включение мобильного контура
`mobile.token.ttl`	Срок жизни токена, секунд
`mobile.signals`	Путь к файлу с перечнем признаков и их весами
`mobile.analyzejs.interval`	Интервал вызова анализа
`mobile.registration.bad_score`	Суммарный вес сработавших признаков, при котором запрос блокируется

Состав признаков, их веса и пороговое значение задаются на стороне сервера.

Изменение этих параметров не требует обновления мобильного приложения и публикации новой версии в магазинах приложений. Это позволяет изменять настройки защиты независимо от цикла выпуска мобильного приложения.

Порядок внедрения¶

Шаг 1. Определите состав собираемых признаков¶

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

Шаг 2. Реализуйте необходимые механизмы в приложении¶

Команда разработки заказчика реализует:

Сбор характеристик устройства.
Вычисление отпечатка.
Шифрование передаваемых данных.
Вызовы программного интерфейса.
Обработку ответов о блокировке.

Шаг 3. Проверьте работу с завышенным порогом¶

Перед включением блокировки запустите мобильный контур со значением bad_score, превышающим достижимый суммарный вес признаков.

В этом режиме признаки собираются и фиксируются, но запросы не блокируются.

Это позволяет оценить распределение срабатываний на реальном трафике мобильного приложения.

Шаг 4. Настройте веса и пороговое значение¶

По результатам проверки скорректируйте веса признаков и пороговое значение.

Шаг 5. Включите блокировку¶

Установите рабочее значение порога bad_score.

Дальнейшая корректировка выполняется на стороне сервера и не требует обновления мобильного приложения.

Соотношение с защитой веб-ресурсов и API¶

Мобильный контур входит в состав SmartBot Protection и не требует отдельной установки.

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

Для всех трёх сред общими являются:

Модель проверки легитимности клиента.
Принцип оценки по совокупности признаков.
Локальная обработка данных.
Настройка параметров на стороне ноды.

Различаются способ начала проверки и состав собираемых характеристик. Эти отличия связаны со средой исполнения.

Развитие механизма¶

Контракт взаимодействия предусматривает поле для передачи поведенческих характеристик. В текущей редакции оно не используется.

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