Токен доступа и проверка запросов¶

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

Назначение¶

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

Токен выполняет три задачи:

• Подтверждает, что клиент уже прошёл проверку.
• Связывает клиента с характеристиками, зафиксированными в момент проверки.
• Ограничивает срок действия ранее принятого решения.

Токен передаётся в cookie и автоматически сопровождает запросы к защищаемым ресурсам. Изменения в приложении заказчика не требуются.

Типы защиты ресурса¶

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

• Fingerprint – проверка по характеристикам соединения и запроса: строке идентификации клиента, отпечатку TLS-соединения и спискам доступа. Наличие токена не требуется и не проверяется. Тип предназначен для ресурсов, к которым обращаются без предварительного посещения страниц: статических файлов, изображений и служебных точек входа.
• Landing – для доступа требуется действующий токен. При его отсутствии или недействительности клиенту показывается страница проверки, по результатам которой выдаётся токен. Тип предназначен для страниц, открываемых пользователем в браузере.
• Token Check – для доступа требуется действующий токен. При его отсутствии или недействительности запрос блокируется без показа страницы проверки. Тип предназначен для программных интерфейсов, где показ HTML-страницы не предусмотрен. Клиент должен получить токен при обращении к странице приложения.

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

Порядок проверки запроса¶

Каждый запрос к защищаемому ресурсу проходит несколько групп проверок.

Проверка по спискам¶

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

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

Проверка подлинности поискового робота¶

Если клиент представляется известным поисковым роботом и не предъявляет токен, выполняется проверка принадлежности его IP-адреса заявленной поисковой системе по обратным DNS-записям.

Робот, прошедший проверку, получает доступ без токена. Если проверка не пройдена, клиент блокируется как поддельный поисковый робот.

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

Порядок проверки описан в Проверке поисковых роботов.

Проверка токена¶

Токен расшифровывается. Проверяются срок его действия, соответствие зафиксированных характеристик текущему запросу и сохранённое в токене решение.

По результатам проверки запрос может быть:

• Пропущен.
• Заблокирован.
• Направлен на страницу проверки.

Действие при неуспешной проверке токена зависит от типа ресурса. Для Landing клиент направляется на повторную проверку, а для Token Check запрос блокируется.

Состав токена¶

Токен содержит характеристики клиента, зафиксированные в момент проверки, принятое решение и срок действия.

Отпечаток клиентского окружения – результат сбора характеристик браузера или устройства.

Отпечаток HTTP-запроса – значение, вычисляемое на стороне сервера из IP-адреса клиента и набора значимых заголовков запроса. Позволяет обнаружить перенос токена в другой клиент. Даже при точном копировании cookie состав и порядок заголовков другого клиента могут отличаться.

Отпечаток TLS-соединения – параметры криптографического рукопожатия клиента.

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

Срок действия – период, в течение которого токен остаётся действительным.

Токен шифруется алгоритмом с контролем целостности. Клиент не может прочитать или изменить его содержимое. Любая модификация делает токен нерасшифровываемым, и он отклоняется. Ключ шифрования хранится на ноде и не передаётся клиенту.

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

Выдача токена¶

Первичная проверка выполняется на странице проверки, где подтверждается легитимность клиента.

Страница собирает характеристики браузера и результаты проверок окружения, затем передаёт их на регистрацию. На стороне ноды выполняются проверки по спискам, вычисляется отпечаток HTTP-запроса и оценивается суммарный вес полученных сигналов.

По результатам оценки возможны три сценария:

• Вес ниже порога подозрительности. Клиент получает токен с разрешающим решением.
• Вес в промежуточном диапазоне. Клиенту предлагается дополнительная проверка. По её результатам выдаётся токен с разрешающим или запрещающим решением.
• Вес выше порога блокировки. Клиент получает токен с запрещающим решением.

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

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

Установка токена на нескольких доменах¶

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

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

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

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

Продление токена¶

Срок действия токена ограничен. Продление выполняется скриптом analyze.js, встроенным в страницы приложения. Порядок встраивания описан в Настройке SmartBot Protection.

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

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

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

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

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

Отсутствие обращений от analyze.js само по себе является признаком того, что страница не была загружена в браузере.

Срок жизни токена¶

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

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

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

Значение подбирается с учётом особенностей конкретного приложения.

Разбор отказов¶

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

Основные основания:

• Токен отсутствует.
• Токен не удалось расшифровать.
• Срок действия токена истёк.
• Отпечаток HTTP-запроса не совпадает.
• Отпечаток TLS-соединения не совпадает.
• Отпечаток клиентского окружения не совпадает.

Эта информация помогает отличать штатные ситуации от попыток обхода защиты.

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

Порядок анализа отказов описан в Мониторинге и анализе заблокированных запросов.

Единство механизма¶

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

• Веб-ресурсы. Первичная проверка выполняется на странице проверки, а продление токена – скриптом analyze.js.
• Программные интерфейсы. Токен, полученный при работе с приложением, предъявляется при обращении к интерфейсу.
• Мобильные приложения. Проверка выполняется через программный интерфейс, а роль страницы проверки выполняет запрос инициализации. Порядок описан в Защите мобильных приложений.

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

При этом настройки задаются отдельно, что позволяет применять к разным средам политики различной строгости.