Безопасность и конфиденциальные данные

Traffic Jam по умолчанию работает с перехваченными учётными данными, сессионными токенами и персональными данными. Его модель безопасности состоит из трёх уровней: секреты маскируются в аналитических представлениях и вырезаются из экспортируемых файлов, которыми можно делиться; replay доступен только после явного подтверждения; все данные перехвата остаются на вашей машине. На этой странице собрано точное описание поведения в одном месте.

[!NOTE] Traffic Jam — инструмент для авторизованного тестирования безопасности и реверс-инжиниринга API. Перехватывайте, воспроизводите и исследуйте только те системы, на тестирование которых у вас есть разрешение.

Что маскируется в аналитических представлениях

Маскирование работает по имени поля и по шаблону значения. Значение маскируется, если имя поля похоже на содержащее учётные данные или если само значение совпадает с известным шаблоном секрета.

Заголовки, маскируемые по точному имени:

Любой заголовок, имя которого содержит api-key, auth, credentials, jwt, secret, session, sign/signature или token, либо оканчивается на компактный суффикс вроде password, privatekey, clientsecret, samlresponse или sessionid, также считается конфиденциальным. Идентификаторы трассировки явно не являются секретами: traceparent, tracestate, x-correlation-id, x-device-id, x-request-id, x-timestamp.

Для параметров query и fragment действуют те же правила по имени поля плюс точные имена code, key и sig.

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

Bearer ••••••••3f2a
••••••••        (значения длиной 8 символов и меньше)

Структурированные тела редактируются на месте с сохранением формы:

• JSON — значения полей с конфиденциальными именами становятся "<redacted>"; ключи объектов, содержащие встроенные учётные данные, становятся "<redacted-key>".
• application/x-www-form-urlencoded — значения конфиденциальных параметров становятся <redacted>.
• multipart/* — части, у которых name является конфиденциальным, заменяются на <redacted>; вложенные части обрабатываются рекурсивно.
• Разметка XML/HTML — конфиденциальные атрибуты и текстовое содержимое конфиденциальных элементов заменяются.
• Простой текст — заменяются токены Bearer/Basic, JWT (eyJ…) и известные шаблоны учётных данных.

Среди распознаваемых шаблонов значений — ключи AWS (AKIA…), токены GitHub (ghp_, gho_, github_pat_), ключи Stripe (sk_live_, pk_), токены Slack (xox[baprs]-) и ключи Google API (AIza…).

Userinfo в URL, сегменты пути в контекстах учётных данных (auth, oauth, token, callback, reset, verify и подобных) и конфиденциальные значения query заменяются везде, где встречаются URL, в том числе внутри заголовков Location, Referer, Content-Location и Link.

Замена в экспорте и копиях

Сгенерированные примеры curl, Python, Postman и OpenAPI по умолчанию редактируются; для получения точных перехваченных значений требуется явное включение. Значения заголовков экспортируются как детерминированные плейсхолдеры (Bearer <redacted>, name=<redacted> для каждой пары cookie), а не как превью •••• из интерфейса, поэтому экспортированный текст безопасно вставлять в отчёт.

Тела, которые нельзя безопасно инспектировать, не утекают: в экспортируемых файлах непрозрачное тело заменяется плейсхолдером <redacted: opaque body> (или <redacted: opaque multipart body>).

Экспорт каталога содержит манифест безопасности и отчёт, чтобы вы точно видели, что было скрыто:

{
  "version": 2,
  "policy": {
    "capturedSensitiveValues": "redacted",
    "opaqueBodies": "omitted",
    "pathCredentials": "redacted"
  },
  "report": {
    "routes": 12, "calls": 340,
    "headerRedactions": 28, "bodyRedactions": 9,
    "urlRedactions": 4, "opaqueBodies": 2, "truncatedBodies": 1
  }
}

При включённом opt-in поля policy переключаются на included-by-explicit-opt-in. Отчёт также предупреждает, если перехваченные тела были усечены (выведенные контракты могут быть неполными) или если непрозрачные тела были опущены. Шаблоны путей тоже санируются: сегменты, похожие на учётные данные, становятся {redacted}, а параметры с именами учётных данных становятся {parameter1}, тогда как обычные UUID и числовые ID остаются нетронутыми. См. /docs/ru/analysis/exports/.

Opt-in на раскрытие

Маскирование включено по умолчанию везде; раскрытие точных значений — это осознанное действие в рамках сессии.

• Аналитические представления — откройте диалог Settings и включите Reveal secrets. Переключатель действует на всё приложение, но только в рамках сессии: при перезагрузке приложения он сбрасывается.
• Replay — в диалоге Replay перехваченные учётные данные исключаются, пока вы не отметите Include captured credentials in this replay (переключатель с предупреждением-щитом). Только после этого реальные значения Authorization/Cookie отправляются в сеть.

Защитные ограничения replay

Replay спроектирован так, чтобы раскрывать поведение единственного перехваченного эндпоинта без побочных эффектов. Бэкенд и workbench обеспечивают следующие значения по умолчанию:

Перед отправкой workbench проверяет метод. Всё, что отличается от GET, HEAD или OPTIONS, считается потенциально изменяющим состояние, и кнопка Send остаётся неактивной, пока вы не отметите Confirm potentially state-changing request. Изменение целевого URL вызывает отдельное подтверждение смены назначения.

[!WARNING] Замены заголовков, которые вы вводите в workbench, считаются осознанными значениями и отправляются ровно в том виде, в каком введены, — они не маскируются повторно. Переопределения учётных данных для A/B-тестирования аналогично отправляются как есть. Используйте это, чтобы проверять собственные токены на эндпоинтах, которые вам разрешено исследовать. См. /docs/ru/replay/workbench/ и /docs/ru/replay/variables/.

Локальная архитектура

Ничего не покидает вашу машину, кроме тех replay, которые вы явно отправляете.

• Хранилище — разобранные сессии сохраняются в SQLite по пути .traffic-jam/traffic-jam-v2.sqlite3 (переопределяется через TRAFFIC_JAM_DB_PATH); артефакты live-перехвата хранятся в .traffic-jam/live-captures (TRAFFIC_JAM_CAPTURE_DIR). Десктопное приложение хранит базу данных в своём каталоге пользовательских данных.
• Loopback API — бэкенд по умолчанию слушает 127.0.0.1:8790 (TRAFFIC_JAM_ADDR).
• Capability-токен — задайте TRAFFIC_JAM_API_TOKEN для API и то же значение как VITE_TRAFFIC_JAM_API_TOKEN для веб-фронтенда; клиенты отправляют его в заголовке X-Traffic-Jam-Token, сравнение выполняется за константное время. Десктопная оболочка генерирует новый случайный токен при каждом запуске и передаёт его бэкенду и рендереру через изолированный preload-мост. Автономный dev-API по умолчанию принимает запросы без аутентификации.
• Allowlist CORS — разрешены только loopback-источники браузера (localhost, 127.0.0.1, ::1) и десктопный источник traffic-jam://app. Точные источники добавляются через разделённый запятыми TRAFFIC_JAM_ALLOWED_ORIGINS. Любой другой Origin отклоняется с HTTP 403.

export TRAFFIC_JAM_API_TOKEN="$(openssl rand -hex 32)"
export VITE_TRAFFIC_JAM_API_TOKEN="$TRAFFIC_JAM_API_TOKEN"

Полный справочник по переменным окружения: /docs/ru/reference/cli-config/.

Ответственное использование

Возможности, которые делают Traffic Jam полезным для реверс-инжиниринга — replay, зондирующие мутации, генерация тестовых JWT-токенов (alg=none, RS-to-HS) и A/B-тестирование учётных данных для исследования BOLA/IDOR — являются двойного назначения. Они предполагают, что вы тестируете системы, которыми владеете или которые вам поручено тестировать по контракту. Обнаружение и маскирование секретов (/docs/ru/security/secrets/) существуют для того, чтобы вы могли исследовать и документировать находки, случайно не распространив действующие учётные данные в экспорт, логи или общие артефакты.