Przekształcanie ruchu HAR Playwright w wyniki zabezpieczeń za pomocą skanera MCP

Inżynierowie QA codziennie zajmują się API, żądaniami HTTP, procesami logowania, automatyzacją przeglądarek, pipeline’ami CI/CD oraz zachowaniem aplikacji. Działa to w dużej mierze na zasadzie przenikania się z bezpieczeństwem aplikacji, co rodzi pytanie: czy ruch generowany przez testy automatyczne nie mógłby służyć jako podstawa do testów bezpieczeństwa?

Jedną z odpowiedzi jest serwer MCP (Model Context Protocol), który skanuje zapisany ruch testowy w poszukiwaniu problemów bezpieczeństwa. Proces jest prosty: uruchamia się automatyzację QA, przechwytuje ruch HTTP, skanuje go pod kątem problemów i wykorzystuje sztuczną inteligencję do interpretacji wyników. Ważne jest to, że skaner nigdy nie wysyła dodatkowych żądań do aplikacji.

Dwa światy dzielące się jednym źródłem danych

Bезpieczeństwo i testy jakościowe są zazwyczaj traktowane jako odrębne działania. Procedura testów jakościowych polega na pisaniu testów, ich wykonywaniu, weryfikacji funkcjonalności oraz tworzeniu raportów. Prace związane z bezpieczeństwem odbywają się gdzie indziej: uruchamianie narzędzi bezpieczeństwa, skanowanie aplikacji, badanie wrażliwości oraz raportowanie ustaleń.

Jednak testy automatyczne już teraz komunikują się z aplikacją. Wywołują API, wysyłają nagłówki autoryzacji i pliki cookie, otrzymują odpowiedzi i kontaktują się z punktami końcowymi. Wszystko to stanowi ruch HTTP i może służyć jako źródło sygnałów dotyczących bezpieczeństwa.

Pliki HAR jako most

Narzędzia takie jak Playwright mogą zapisywać aktywność sieciową przeglądarki jako plik HAR (HTTP Archive). Każda transakcja HTTP zawarta w nim obejmuje szczegóły, w tym:

• Adresy URL i metody HTTP
• Nagłówki żądania i odpowiedzi
• Pliki cookie
• Ciała żądań i odpowiedzi
• Kody stanu i inne metadane

To daje pipeline, który zaczyna się od automatyzacji kontroli jakości i kończy na skanowaniu ruchu, który został wygenerowany:

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

Nie powstaje żaden nowy ruch sieciowy. Skaner analizuje to, co już zostało zarejestrowane podczas testów, co sprawia, że podejście to jest pasywne.

Architektura

Skaner to narzędzie napisane w TypeScript, które czyta pliki HAR i szuka sygnałów istotnych dla bezpieczeństwa. Jego struktura jest celowo prosta:

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

Kluczową decyzją projektową było podzielenie parsera HAR, uznormalizowanego modelu transakcji, zasad bezpieczeństwa oraz silnika skanowania na odrębne części. Tylko parser zajmuje się formatem HAR. Zasady nigdy nie widzą oryginalnej struktury HAR i pracują z uznormalizowanymi transakcjami, dzięki czemu dodanie nowej zasady później jest proste.

Kontrole w pierwszej wersji

Brak HSTS. Skaner zaznacza odpowiedzi, które nie zawierają tego nagłówka:

Strict-Transport-Security

HSTS sprawia, że przeglądarki wymagają używania HTTPS, i stanowi istotną część bezpiecznej konfiguracji.

Zwykły HTTP. Zapytania wysyłane przez

http://

Zamiast

https://

wskazuje na przypadkowo niesecure punkty końcowe, które pojawiają się podczas zwykłych testów.

Atrybuty plików cookie. Sprawdza się pliki cookie pod kątem flag ochronnych:

Secure
HttpOnly
SameSite

Cookie autoryzacyjny lub sesyjny, który nie ma odpowiednich atrybutów, wymaga sprawdzenia.

Wartości przypominające hasła w odpowiedziach. Wyobraź sobie odpowiedź w takim wydaniu:

{
  "apiKey": "..."
}

Wartość przypominająca dane uwierzytelniające, która jest zwracana do klienta, stanowi potencjalny problem. Jest to szczególnie istotne, ponieważ testy jakości mogą na nią natrafić przypadkowo, bez konieczności pisania dedykowanego testu bezpieczeństwa w tym celu.

Wrażliwe parametry URL. Sekrety czasami trafiają do adresów URL:

/api/user?token=...

Skaner sprawdza adresy URL pod kątem nazw parametrów oraz wzorów, które wydają się wrażliwe. Adresy URL trafiają do dzienników, historii przeglądania, proxy, systemów analitycznych i innych miejsc, więc to ma znaczenie.

Numerzy kart płatniczych. Było to jedno z ciekawszych zasad. Skaner wykrywa wartości przypominające numery kart i weryfikuje je za pomocą algorytmu Luhna. Losowy 16-cyfrowy numer niewiele mówi, ale wartość przypominająca numer kartę i przechodząca weryfikację Luhna jest silniejszym znakiem, że dane płatnicze mogą zostać ujawnione. Ta zasada łączy wykrywanie wzorów z rzeczywistą weryfikacją.

Ryzykowne ustawienia CORS. Skaner szuka niebezpiecznych kombinacji. Origin typu wildcard:

Access-Control-Allow-Origin: *

wraz z dozwolonymi uprawnieniami:

Access-Control-Allow-Credentials: true

wymaga zbadania. Wykrywa również serwery, które wydają się odbijać wartość Origin żądania bez odpowiedniej weryfikacji.

Umożliwienie wykorzystania skanera przez sztuczną inteligencję

Model Context Protocol to standardowy sposób, w jaki aplikacje oparte na sztucznej inteligencji mogą korzystać z zewnętrznych narzędzi i danych. Zamiast ograniczyć się do samodzielnego skanera, projekt udostępnia go jako narzędzie dostępne dla sztucznej inteligencji. Serwer MCP publikuje jedno takie narzędzie:

secscan_scan_har

Klient korzystający z AI dostarcza plik HAR, uruchamia skaner i otrzymuje strukturyzowane wyniki. Przepływ wygląda w ten sposób:

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

Czytanie raportu linijka po linijce nie jest już jedyną opcją, ponieważ można po prostu zadać pytania dotyczące uzyskanych wyników. Typowe pytania to na przykład, które ustalenia charakteryzują się najwyższym stopniem powagi, co jest powiązane z procesem autoryzacji lub dlaczego określona konfiguracja CORS stanowi zagrożenie. Skaner dostarcza dowody, a sztuczna inteligencja pomaga je wyjaśnić.

Unikanie udziału sztucznej inteligencji w decyzjach o zatwierdzeniu/lukce

Sztuczna inteligencja doskonale radzi sobie z wyjaśnianiem ustaleń, podsumowywaniem wyników, pomaganiem w analizie dowodów, proponowaniem rozwiązań oraz odpowiadaniem na pytania dotyczące skanowania. Jednak wdrożenie w środowisku produkcyjnym nie powinno zależeć od tego, czy model uważa, że coś jest podatne na ataki. Dlatego projekt obejmuje również deterministyczną bramkę bezpieczeństwa CLI:

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

Gdy pojawiają się krytyczne ustalenia, skaner może spowodować niepowodzenie procesu budowania. Daje to dwa oddzielne rozwiązania. Pierwszym jest analiza wspomagana przez sztuczną inteligencję:

AI-Assisted Analysis

HAR
 ↓
MCP
 ↓
AI
 ↓
Explain / Investigate / Triage

Drugi to deterministyczna brama bezpieczeństwa:

Deterministic Security Gate

HAR
 ↓
Scanner
 ↓
Critical Finding?
 ↓
FAIL BUILD

Rozdzielenie tych elementów ma znaczenie. Wykorzystuj sztuczną inteligencję tam, gdzie rozumowanie i interakcja dodają wartości, a deterministyczne reguły tam, gdzie decyzje o sukcesie lub niepowodzeniu muszą być przewidywalne.

Włączenie tego do pipeline Playwright

Rozważmy istniejące zadanie CI w Playwright z jego standardowym krokiem testowym:

- name: Run Playwright tests
  run: npx playwright test

Dodaj krok zabezpieczeniowy tuż po nim:

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

Te same testy QA dostarczają teraz dwa rodzaje dowodów: funkcjonalne i związane z bezpieczeństwem. Ogólny proces pracy wygląda wtedy w ten sposób:

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

To jest najbardziej atrakcyjny aspekt tego pomysłu. Odrębny proces bezpieczeństwa nie zawsze jest konieczny dla każdego podstawowego sygnału, ponieważ niektóre sprawdzenia mogą odbywać się naturalnie w ramach istniejącego procesu QA.

Trudne pytanie projektowe

Napisanie serwera MCP nie było trudnym elementem. Trudno było zdecydować, jak strukturyzować dane pomiędzy parserem HAR a regułami bezpieczeństwa. HAR to szczegółowy format, a jeśli każda reguła musi go rozumieć bezpośrednio, konserwacja szybko staje się skomplikowana. Rzeczoznawstwo pośrednie rozwiązuje ten problem:

HAR
 │
 ▼
Parser
 │
 ▼
Transaction
 │
 ▼
Security Rules

Zasady nie przejmują się tym, skąd pochodzi transakcja. Otrzymują coś, co już rozumieją, co ułatwia rozbudowę skanera.

Co może nastąpić dalej

To jest pierwsza wersja, z dużym potencjałem rozwoju. Sprawdzania kandydatów obejmują:

• Analizę polityki bezpieczeństwa treści
• X-Content-Type-Options i Referrer-Policy
• Problemy z Cache-Control
• Ujawnienie JWT
• Słabości w autoryzacji i sesjach
• Ujawnienie danych wrażliwych
• Więcej sprawdzeń CORS
• Sygnały związane z uprawnieniami

Wyniki mogą również zawierać bardziej szczegółowe dowody, przedstawione w takim formacie:

Finding
Severity
Rule
Evidence
Request
Response
Impact
Remediation

Kwarstwa MCP może w przyszłości odpowiadać na pytania takie jak „Które ustalenia należy zbadać najpierw?”, „Czy kilka ustaleń jest spowodowanych tym samym problemem konfiguracji?” oraz „Wyjaśnij to ustalenie programiście.”

Kolejnym kierunkiem jest integracja z CI: GitHub Actions, komentarze dotyczące bezpieczeństwa w pull requestach, wyniki SARIF, progi poważności, podstawowe ustalenia oraz wykrywanie regresji bezpieczeństwa. Celem jest to, aby testy bezpieczeństwa wydawały się jeszcze jedną bramką jakościową, a nie oddzielnym obszarem.

Dlaczego specjaliści od QA są w idealnej pozycji

Znaczna część pracy inżynierów QA każdego dnia stanowi również podstawę bezpieczeństwa aplikacji: HTTP, API, autoryzacja i uwierzytelnianie, automatyzacja testów, CI/CD, analiza zachowania i awarii aplikacji. Tworzenie narzędzi pogłębia zrozumienie tematu bardziej niż same kursy czy certyfikaty. Taki projekt obejmuje kolejno analizę plików HAR, bezpieczeństwo HTTP, pliki cookie, CORS, wykrywanie tajnych i wrażliwych danych, reguły bezpieczeństwa, MCP, mechanizmy CLI oraz procesy CI/CD.

Korzyści wykraczają poza zwykłe repozytorium – pokazują one, jak dane z automatyzacji testów QA mogą stać się informacjami wykorzystywanymi do ochrony bezpieczeństwa. Testy już obserwują zachowanie aplikacji, pliki HAR zapisują to w ustrukturyzowanej formie, reguły wyodrębniają z ruchu sieciowego użyteczne sygnały, a MCP umożliwia klientom opartym na sztucznej inteligencji korzystanie z tych funkcji. Wszystko to razem tworzy jedną spójną koncepcję:

QA Automation
      +
Application Security
      +
AI
      +
DevSecOps

Główny wniosek jest taki, że testowanie bezpieczeństwa nie musi zaczynać się od kolejnego skanowania. Może rozpocząć się od testów ruchu, które już zostały przeprowadzone. Automatyzacja testów jakości, bezpieczeństwo aplikacji, sztuczna inteligencja oraz DevSecOps razem mogą przynieść większe rezultaty i objąć szerszy zakres niż którykolwiek z tych elementów samodzielnie.