Мутационные пробы и жизненный цикл токенов
Пробы мутаций антифрода с детекцией накопленных отказов и отслеживание свежести токенов.
Обе функции находятся в рабочей области Collector представления API. Мутационные пробы активно выполняют replay изменённых запросов, чтобы выяснить, что допускает антифрод-система; жизненный цикл токенов пассивно читает ваши записи, чтобы понять экономику сессии. Запускайте пробы только против систем, тестирование которых вам явно разрешено — каждая проба отправляет реальные запросы на цель.
[!WARNING] Мутационные пробы намеренно отправляют подменённый трафик (ротированные cookie, поддельные поля устройства) на продакшн-бэкенд антифрода. Это активное тестирование. Убедитесь, что у вас есть разрешение на работу с целью, прежде чем нажимать Run probe.
Запуск мутационной пробы
Откройте рабочую область Collector → вкладка Probes. Панель принимает один захваченный запрос и список однополевых мутаций:
- Выберите запрос Probe target в селекторе сессий/запросов.
- В блоке Mutations выберите расположение, введите имя поля и значение-замену, затем нажмите Add. Повторите для каждого поля, которое хотите проверить.
- Оставьте флажок Pairwise pass включённым (он показывает число пар,
N×(N−1)/2) и нажмите Run probe.
Проба выполняет replay baseline (запрос в том виде, в каком он был захвачен), затем по одному replay на каждую одиночную мутацию, затем по одному replay на каждую пару. Выполнение разбивается на части с учётом лимита бэкенда в 50 запросов на батч, а кнопка показывает живой прогресс done/total.
Как применяются мутации
Каждая мутация нацелена на одно расположение. Мутации cookie и тела сохраняют всё остальное в запросе:
| Расположение | Что переписывает |
|---|---|
header | Устанавливает или переопределяет указанный заголовок запроса. |
cookie | Переписывает указанный cookie внутри заголовка Cookie (добавляется, если отсутствует); все остальные cookie сохраняются. |
query | Устанавливает указанный query-параметр в URL запроса. |
body-json | Устанавливает поле по точечному пути в JSON-теле запроса, например data.cs.gssc. |
[!NOTE] Pairwise включён по умолчанию только при 12 или менее мутациях, поскольку число пар растёт квадратично. Снимите флажок, чтобы выполнить только одиночные пробы.
Детекция накопленных отказов
Смысл pairwise-прогона — в случае, который не видит одиночный прогон: две мутации, каждая из которых принимается по отдельности, но отклоняется в сочетании. Пара помечается как накопленный отказ (stacked rejection), когда обе её одиночные мутации были приняты, а совмещённый replay — нет. Накопленные строки подсвечиваются в отчёте и вызывают предупреждающий тост. Строка сводки гласит, например, 3/4 mutations accepted alone; 2 pairs rejected when stacked.
Чтение отчёта пробы
Таблица результатов перечисляет baseline, одиночные пробы, затем пары с их HTTP-статусом и вердиктом. Replay считается accepted, когда сервер не вернул класс отказа и статус 2xx/3xx; редиректы считаются принятыми, потому что replay никогда по ним не следует. В противном случае вердикт показывает класс отказа:
| Класс отказа | Значение |
|---|---|
antifraud-reject | Отказ антифрода (HTTP 451). |
unauthorized / forbidden / not-found | HTTP 401 / 403 / 404. |
rate-limited | HTTP 429. |
client-certificate-required | Барьер mTLS (400 с телом о клиентском сертификате). |
client-error / server-error | Прочие 4xx / 5xx. |
transport-error | Нет ответа (таймаут, пропущено, сбой соединения). |
Мутация, которая переводит baseline из accepted в antifraud-reject, выявляет поле, к которому привязывается логика антифрода. Полный словарь отказов см. в /docs/ru/replay/workbench/, а управление TLS-отпечатком при replay — в /docs/ru/replay/fingerprints/.
Правила согласованности идентичности устройства
Когда вы запускаете conformance diff (Collector → вкладка Conformance → Run conformance diff), тот же прогон применяет правила идентичности устройства к декодированным телам телеметрии и заголовкам запросов целевого захвата. Они ловят внутренне несогласованный отпечаток устройства раньше, чем это сделает сервер. Нарушения отображаются как бейдж ruleId плюс сообщение (до 10 в списке):
| Правило | Серьёзность | Проверяет |
|---|---|---|
android-sdk-release | high | Целое AndroidSDK соответствует объявленному AndroidRelease (например, release 13 → SDK 33). |
display-dims | high | Логический размер экрана = ceil(px / (dpi/160)). |
platform-hardware | high | Платформа в sysInfo равна PhoneHardware. |
ua-build-tag | high | Build/<tag> в user-agent равен PhoneID. |
fingerprint-release / -brand / -device | warning | Части Build.FINGERPRINT соответствуют release, brand, device. |
device-model-cardinality | high | Один device-id заявляет более одной модели (должно быть 1:1). |
session-device-cardinality | warning | Один device-id ротировался через более чем 3 сессионных cookie. |
Таким образом, поля, которые должны меняться согласованно: SDK↔release, пиксельные размеры↔плотность, platform↔hardware, build-тег UA↔PhoneID и device-id↔model. Мутация одного без других — именно то, что помечают эти правила и сервер.
Отслеживание жизненного цикла токенов
Conformance-прогон также строит отчёт о жизненном цикле токенов для целевой сессии. Он пассивен: читает заголовки ответов Set-Cookie и JSON-поля ответов в форме токена как события mint (JSON-поля именуются json:<leaf>, так что data.cs.gssc становится json:gssc), cookie запросов — как события consume, и отмечает, когда сгенерированное значение позже передаётся в URI запроса. Каждое уникальное значение отслеживается по отпечатку из 8 символов плюс длина, а каждый ответ, в котором оно появляется, записывается как исход.
Значение протухло (went stale), когда оно было успешным (статус < 400, без отказа), а позже было отклонено. Исходя из этого, каждый токен получает класс протухлости:
| Протухлость | Назначается, когда |
|---|---|
freshness-bound | ≥2 отслеживаемых значений и ≥50% были успешны, а затем отклонены. |
single-use-suspected | ≥3 значений и ≥80% встречаются ровно один раз. |
reusable | Значения наблюдались, ни одно не протухло. |
unknown | Недостаточно данных для решения. |
Для протухших токенов отчёт вычисляет окно свежести (мин/медиана/макс миллисекунд между последним успехом и первым отказом). Панель перечисляет топ-10 токенов с именем, бейджем протухлости и minted N× · consumed N× · in URIs N×.
Чтение подсказок модели сессии
Над списком токенов отчёт выводит подсказки простым языком, которые напрямую соотносятся с тем, как collector должен обращаться с каждым токеном:
- Bootstrap один раз, переиспользовать: сгенерированные токены, которые никогда не протухли — получите один раз и переиспользуйте кортеж.
- Выводить или обновлять на каждый запрос: одноразовые или freshness-bound токены — пересчитывайте или перегенерируйте при каждой отправке (см. /docs/ru/replay/variables/ про вычисляемые поля и /docs/ru/collector/signatures/ про восстановление вывода).
- Сгенерированы вне захвата: используются, но никогда не генерировались в записи — перед replay требуется внешний bootstrap-шаг.