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

При первом посещении сайта приложение пользователя (например, браузер или мобильное приложение) получает в качестве ответа статус 401 Unauthorized и страницу с кодом на JavaScript, который собирает данные о цифровом отпечатке окружения пользователя и отправляет их на сервер Qrator Labs. Если этот сервер определяет окружение как легитимный браузер, то он назначает пользователю трекинговую cookie. После этого пользователь некоторое время может просматривать сайт без дополнительных проверок, при этом каждый раз Qrator Labs автоматически продлевает срок действия cookie. Если же сервер Qrator Labs определяет пользователя как бота, то он не устанавливает cookie, а вместо содержимого страниц возвращает ошибку 403 Forbidden.

Для разных адресов вы можете настроить, как Qrator Labs будет реагировать на пользователя без трекинговой cookie: либо отвечать статусом 401 Unauthorized с кодом для проверки окружения, либо отвечать статусом 403 Forbidden.

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

Использование капчиИспользование капчи

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

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

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

Настройка ответа 403 ForbiddenНастройка ответа 403 Forbidden

Если не прошедший проверку пользователь делает запрос к URL, для которого в разделе Bot protection → Локации установлено правило Принять Только с Куки, то сервер Qrator Labs отправляет ему ответ с кодом 403 Forbidden. По умолчанию в качестве тела ответа отправляется простая HTML-страница, дублирующая код ответа.

Вы можете настроить ответ несколькими способами.

• Предоставьте пользователю дополнительную информацию на странице 403 Forbidden

  Qrator Labs возвращает HTML-страницу для статуса 403 Forbidden, когда в заголовке Accept запроса присутствует тип text/html или этот заголовок отсутствует. Эту страницу увидят прежде всего легитимные пользователи, в отношении которых произошло ложноположительное срабатывание проверки.

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

  Чтобы сервер Qrator Labs использовал ваш вариант страницы, загрузите файл 403.html в раздел Страницы ошибок личного кабинета.

• Предусмотрите вариант ответа в формате JSON

  Qrator Labs может возвращать JSON-ответ для статуса 403 Forbidden, когда в заголовке Accept запроса присутствует тип application/json и отсутствует тип text/html. Такое поведение особенно удобно для одностраничных или мобильных приложений, которые могут самостоятельно показать пользователю то или иное сообщение в зависимости от ответа сервера.

  Ответ может содержать идентификатор, позволяющий отличить ответ сервера Qrator Labs от ответа апстрима, а также дополнительную информацию, такую как время получения запроса или строку из заголовка Referer.

  Чтобы включить это поведение и согласовать содержимое JSON-ответа, обратитесь к специалистам технической поддержки Qrator Labs.

• Используйте HTTP-заголовки при проверке ответа

  HTTP-заголовки — ещё один способ сообщить одностраничному или мобильному приложению, какой сервер отправил ответ на их запрос: апстрим или сервер Qrator Labs. Чаще всего для этого достаточно всего одного заголовка, который будет указан в ответе 403 Forbidden сервера Qrator Labs, но заведомо будет отсутствовать в ответе апстрима.

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

Примеры интеграцииПримеры интеграции

Защита веб-сайта с использованием cookieЗащита веб-сайта с использованием cookie

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

Пользователь начинает просмотр сайта с любой страницы, и при первом посещении Qrator Labs выполняет проверку и устанавливает cookie. Если срок действия cookie истечёт, то при очередном обращении к сайту проверка будет выполнена повторно. В то же время боты не смогут пройти проверку и будут получать ошибку 401 Unauthorized на любой странице.

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

Защита мобильных API с использованием cookieЗащита мобильных API с использованием cookie

Предположим, что у вас есть приложение, которое делает запросы к вашему API-шлюзу (API gateway) и может обрабатывать полученные от него данные, но не сможет обработать страницу HTML с кодом на JavaScript. Это частая ситуация, например, для мобильных приложений.

В такой ситуации рекомендуется настроить установку и проверку трекинговой cookie на разных страницах:

1. Добавьте в карту приложения URL, предназначенный для посещения из браузерного окружения.

2. Для этой страницы в личном кабинете Qrator Labs включите проверку отпечатка с последующей выдачей трекинговой cookie.

3. Добавьте в клиентский код приложения обращение к этому URL через браузер. Например, приложение может показывать HTML-страницу с сервера в компоненте WebView в качестве экрана загрузки, а затем извлекать из хранилища WebView полученную cookie. Если вы используете капчу, убедитесь, что у пользователя будет возможность ввести символы в поле ввода.

4. Приложение должно использовать полученную cookie в последующих запросах к API-шлюзу. Когда срок действия cookie истечёт, необходимо повторно направить пользователя на страницу проверки.

Защита мобильных API с использованием хэшаЗащита мобильных API с использованием хэша

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

Для таких приложений можно использовать проверку хэша, для вычисления которого используются HTTP-заголовки запроса и секретный ключ, известный только вам и Qrator Labs:

1. В разделе Bot protection → Локации установите правило Принять Только с Куки для всех страниц, которые должны быть под защитой.

   При такой настройке сервер Qrator Labs будет считать легитимными посетителей либо с корректной cookie, либо с корректным хэшем в HTTP-заголовках.

2. В разделе Bot protection → Подписи добавьте новую подпись и включите проверку подписей.

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

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

Боты, не владеющие ключом, не смогут добавлять к запросам корректный хэш. Qrator Labs не будет направлять такие запросы API-шлюзу.