Преобразование трафика HAR Playwright в результаты анализа безопасности с помощью сканера MCP

Инженеры по тестированию ежедневно работают с API, HTTP-запросами, процессами входа, автоматизацией браузеров, пайплайнами CI/CD и поведением приложений. Эта деятельность в значительной степени пересекается с обеспечением безопасности приложений, что поднимает вопрос: не могут ли трафик автоматизированных тестов уже служить двойным источником данных для тестирования на безопасность?

Одним из решений является сервер MCP (Model Context Protocol), который сканирует записанный трафик тестов на наличие проблем с безопасностью. Пайплайн прост: запускается автоматизация тестирования, фиксируется HTTP-трафик, он сканируется на наличие проблем, а ИИ помогает интерпретировать полученные результаты. Примечательно то, что сканер никогда не отправляет дополнительные запросы к приложению.

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

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

Однако автоматизированные тесты уже взаимодействуют с приложением. Они вызывают API, отправляют заголовки аутентификации и куки, получают ответы и обращаются к конечным точкам. Все это представляет собой трафик HTTP, который может служить источником сигналов, связанных с безопасностью.

Файлы HAR как мост

Инструменты вроде Playwright могут сохранять сетевую активность браузера в виде файла HAR (HTTP Archive). Каждая операция HTTP в таком файле содержит следующую информацию:

• URL-адреса запросов и методы HTTP
• Заголовки запросов и ответов
• Куки
• Тела запросов и ответов
• Коды состояния и другие метаданные

Это создаёт цепочку операций, которая начинается с автоматизации тестирования качества и заканчивается анализом трафика, генерированного в результате:

QA Automation
      │
      ▼
HTTP Traffic
      │
      ▼
    HAR File
      │
      ▼
Security Scanner
      │
      ▼
Security Findings

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

Архитектура

Сканер — это инструмент на TypeScript, который читает файлы HAR и ищет сигналы, связанные с безопасностью. Его структура преднамеренно проста:

Playwright
                        │
                        ▼
                 Network Traffic
                        │
                        ▼
                     HAR File
                        │
                        ▼
                   HAR Parser
                        │
                        ▼
              Normalized Transactions
                        │
                        ▼
                 Security Rules
                   │         │
                   ▼         ▼
                MCP Tool   CLI Gate
                   │         │
                   ▼         ▼
                 AI        CI/CD

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

Проверки в первой версии

Отсутствует HSTS. Сканер отмечает ответы, в которых отсутствует этот заголовок:

Strict-Transport-Security

HSTS заставляет браузеры требовать использования HTTPS, и это важная часть безопасной конфигурации.

Обычный HTTP. Запросы, отправляемые по

http://

вместо того чтобы

https://

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

Атрибуты куки. Проверяются наличие защитных флагов у куки:

Secure
HttpOnly
SameSite

Куки аутентификации или сессии, у которых отсутствуют необходимые атрибуты, заслуживают внимания.

Значения, похожие на секреты, в ответах. Представьте себе ответ вроде следующего:

{
  "apiKey": "..."
}

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

Конфиденциальные параметры URL. Иногда секретная информация попадает в URL:

/api/user?token=...

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

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

Рискованные настройки CORS. Сканер ищет опасные комбинации. Например, использование шаблона исходного адреса:

Access-Control-Allow-Origin: *

Вместе с разрешенными учетными данными:

Access-Control-Allow-Credentials: true

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

Сделать сканер доступным для использования ИИ

Model Context Protocol — это стандартный способ для приложений ИИ использовать внешние инструменты и данные. Вместо того чтобы ограничиваться автономным сканером, проект предоставляет его в качестве инструмента, доступного для вызова ИИ. Сервер MCP публикует один такой инструмент:

secscan_scan_har

Клиент на основе ИИ предоставляет файл HAR, запускает сканер и получает структурированные результаты. Поток работ выглядит следующим образом:

HAR File
                 │
                 ▼
            MCP Server
                 │
                 ▼
          Security Scanner
                 │
                 ▼
          Security Findings
                 │
                 ▼
            AI Client
                 │
                 ▼
        Explain / Investigate

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

Исключение ИИ из процесса принятия решений о прохождении/непрохождении

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

npm run gate -- test-results/network.har

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

AI-Assisted Analysis

HAR
 ↓
MCP
 ↓
AI
 ↓
Explain / Investigate / Triage

Второй — это детерминистический защитный барьер:

Deterministic Security Gate

HAR
 ↓
Scanner
 ↓
Critical Finding?
 ↓
FAIL BUILD

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

Интеграция в пайплайн Playwright

Рассмотрим существующую задачу CI в Playwright с её обычным шагом тестирования:

- name: Run Playwright tests
  run: npx playwright test

Добавьте шаг безопасности сразу после него:

- name: Security Gate
  run: npm run gate -- test-results/network.har

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

Code
 │
 ▼
Build
 │
 ▼
Playwright Tests
 │
 ▼
Capture HAR
 │
 ▼
Passive Security Scan
 │
 ▼
Security Gate
 │
 ▼
Deploy

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

Сложный дизайнерский вопрос

Написание сервера MCP не было сложной частью. Сложность заключалась в том, чтобы решить, как структурировать данные между парсером HAR и правилами безопасности. HAR — это детализированный формат, и если каждое правило должно понимать его напрямую, техническое обслуживание становится крайне сложным. Промежуточное представление решает эту проблему:

HAR
 │
 ▼
Parser
 │
 ▼
Transaction
 │
 ▼
Security Rules

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

Что может последовать дальше

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

• Анализ политики безопасности контента
• X-Content-Type-Options и Referrer-Policy
• Проблемы с Cache-Control
• Раскрытие информации в формате JWT
• Слабые места в процессах аутентификации и сессий
• Раскрытие конфиденциальных данных
• Дополнительные проверки CORS
• Сигналы, связанные с авторизацией

Результаты проверок также могут включать более подробные доказательства в таком формате:

Finding
Severity
Rule
Evidence
Request
Response
Impact
Remediation

Слой MCP в будущем сможет отвечать на вопросы вроде «Какие находки следует исследовать в первую очередь?», «Являются ли несколько находок следствием одной и той же проблемы конфигурации?» и «Объясните эту находку разработчику».

Ещё одним направлением является интеграция с CI: GitHub Actions, комментарии по вопросам безопасности к pull-запросам, вывод SARIF, пороги серьезности, базовые находки и выявление регрессий в области безопасности. Цель состоит в том, чтобы тестирование безопасности воспринималось как ещё один этап контроля качества, а не как отдельная сфера.

Почему специалисты по QA находятся в идеальном положении

Большая часть работы инженеров по тестированию каждый день также является основой безопасности приложений: HTTP, API, механизмы аутентификации и авторизации, автоматизация тестирования, CI/CD, анализ поведения приложений и причин сбоев. Разработка инструментов позволяет глубже понять эти аспекты, чем это возможно только с помощью курсов или сертификатов. Подобный проект поочередно охватывает парсинг файлов HAR, безопасность HTTP, куки, механизм CORS, обнаружение секретных и конфиденциальных данных, правила безопасности, технологию MCP, инструменты CLI и процессы CI/CD.

Польза от такого подхода выходит за рамки просто создания ещё одного репозитория: он демонстрирует, как данные автоматизации тестирования могут превратиться в информацию для обеспечения безопасности. Тесты уже отслеживают поведение приложений, файлы HAR записывают его в структурированном виде, правила извлекают полезные сигналы из трафика, а технология MCP позволяет ИИ-клиентам использовать эти возможности. Все это вместе формирует единую концепцию:

QA Automation
      +
Application Security
      +
AI
      +
DevSecOps

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