Выявить кражу cookie или токена

Как с помощью данных DFP понять, что аутентификационную cookie или токен пользователя украли, и не дать злоумышленнику войти в аккаунт.

Какую проблему решаем

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

Злоумышленники этим пользуются: крадут cookie/токен и логинятся от имени настоящего владельца.

DFP помогает с этим бороться. Благодаря ему вы видите, из какого окружения заходит пользователь. Если старая cookie/токен используется в новом браузере/устройстве, скорее всего, данные украли — лучше попросить ввести логин и пароль заново.

Как настроить

На вашем бэкенде

Как будет работать сценарий

Обычно в вашей базе данных уже хранится связь между выданными cookie/токенами и аккаунтами. Например:

Cookie или токен Аккаунт

session_7fa91c

mira

session_21bd04

alex

token_98c2ab

max

Добавьте к этой логике проверку окружения. Каждый раз, когда пользователь проходит аутентификацию, запускайте DFP и получайте user_id — идентификатор окружения. Храните связь аккаунта не только с cookie или токеном, но и с user_id.

Подробнее о user_id

user_id — стабильный идентификатор клиентского окружения.

Говоря проще, это ID, который описывает уникальную связку браузер + конкретное устройство. Он остаётся стабильным, даже когда пользователь меняет у себя настройки. Например, если он:

  • включит VPN;

  • откроет инкогнито;

  • обновит ОС;

  • поменяет время на компьютере;

  • обновит версию браузера.

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

А вот если откроет другой браузер или сделает запрос с нового устройства, вы увидите новый ID. Потому что для каждой пары браузер + устройство ID уникален.

Протестируйте, как это работает, в нашем playground: открывайте его из разных браузеров, включайте и выключите VPN, переходите в инкогнито или меняйте настройки устройства. Вы увидите, что User ID будет меняться только в двух случаях: если изменилось устройство или браузер. В остальных останется прежним.

Playground DFP

Например:

Аккаунт Cookie или токен user_id

mira

session_7fa91c

user_4b8c21

mira

session_8de22a

user_91f03d

mira

token_42ac10

user_4b8c21

Бэкенд видит, из каких окружений и с какими данными пользователь уже входил в аккаунт. Если старый токен внезапно приходит с новым user_id, это подозрительно — лучше попросить ввести логин и пароль заново.

Помимо user_id советуем использовать bot_score — он покажет, человек или бот пытается войти в аккаунт. Из соображений безопасности ботам лучше отказывать в автоаутентификации.

Подготовка

Интегрируйте DFP со своим сайтом по нашей инструкции.

Настройка бэкенда

  1. Расшифруйте ответ DFP.

  2. Проверьте timestamp (это важно для защиты от replay-атак):

    • Ответ свежий — можно переходить к следующему шагу.

    • Ответ старше нескольких секунд — отклоните результат DFP и не выполняйте автоматическую аутентификацию по cookie или токену. Фронтенд должен заново вызвать DFP, получить свежий payload и отправить его на бэкенд. Если свежий payload получить не удалось, попросите пользователя войти по логину и паролю.

  3. Проверьте bot_score:

    • Меньше 0.4 — признаков автоматизации нет. Можно продолжать проверку.

    • От 0.4 — есть риск, что запрос делает бот. Откажите в автоматической аутентификации и попросите пользователя ввести логин и пароль заново.

  4. Пользователь пытается войти со своей cookie или токеном. Проверьте, есть ли для этой cookie/токена сохранённый user_id:

    • Нет — это нормальная ситуация, если вы недавно подключили DFP и пользователь с тех пор ещё не заходил в аккаунт, то есть DFP его ещё не проверял. Сохраните текущий user_id в БД и пропустите пользователя.

    • Да — переходите к следующему шагу.

  5. Сравните сохранённый раньше user_id с новым user_id:

    • Значения совпадают — пользователь входит из знакомого окружения, всё в порядке. Аутентифицируйте его.

    • Значения не совпадают — скорее всего, cookie или токен украли и теперь используют из другого браузера или устройства. Откажите в автоаутентификации и попросите пользователя ввести логин и пароль заново. Если он не сможет войти, значит, это был злоумышленник. Если войдёт, выпустите новый токен и сохраните для него новый user_id.

Логика решения в виде блок-схемы:

Блок-схема: проверка кражи cookie или токена

На стороне Servicepipe

Можем взять реализацию этой логики на себя.

Мы будем хранить связь между cookie или токенами вашего сервиса и user_id. Если пользователь входит со старой cookie/токеном из нового окружения, DFP пришлёт вам сигнал: возможно, данные украл злоумышленник.

Такую механику мы настраиваем индивидуально по запросу. Наши инженеры согласуют с вами, как будет работать проверка, в каком формате будем получать данные о cookie/токене и в каком формате возвращать результат.

Напишите нам, мы обсудим решение и реализуем его под ваш сценарий.