OWASP ZAP dla QA — skan, triage i koniec

Ten wpis jest częścią serii Podstawy testowania bezpieczeństwa. Jeśli pominąłeś poprzedni, przeczytaj Część 1 — Mindset testów bezpieczeństwa.

Wprowadzenie — skaner to lista, nie werdykt

ZAP pogada z aplikacją i odda alerty. Część jest prawdziwa. Część to nagłówki, które już świadomie akceptujecie. Część odpala się, bo skaner nie był zalogowany i zobaczył stronę logowania.

Praca to triage. Skan jest tani.

Gdzie wolno skanować

Odpalaj ZAP na stagingu, który wolno zepsuć. Skan aktywny wysyła złośliwe payloady. Utworzy dane, zablokuje konta i wytrąci limity.

Nie kieruj skanu aktywnego na produkcję. Bierne spojrzenie na produkcję to osobna, węższa decyzja i nadal potrzebuje ludzi, którzy odpowiadają za serwis.

Daj skanerowi użytkownika. Anonimowy crawl aplikacji za logowaniem testuje stronę marketingową.

Najpierw baseline

Do pierwszego przejścia wystarczy Automation Framework. Baseline trochę chodzi po stronie i zgłasza znaleziska pasywne. Nie próbuje exploitować.

docker run --rm -v "$(pwd):/zap/wrk:rw" -t ghcr.io/zaproxy/zaproxy:stable \
  zap-baseline.py -t https://staging.example.com -r zap-report.html

Raport HTML czytaj z deweloperem, który zna aplikację. Szukasz trzech rzeczy:

znaleziska, które odtworzysz w przeglądarce albo curlem
adresu i parametru, nie samej nazwy wtyczki
decyzji: naprawić, zaakceptować albo „skaner się zgubił”

Co wyrzucić

Odrzuć alert, gdy:

dotyczy tylko skryptu trzeciej strony, którego nie wysyłacie
ten sam nagłówek jest już zapisanym, akceptowanym ryzykiem
nie odtwarzasz go zalogowany jako użytkownik skanera
URL to wylogowanie, health check albo plik statyczny

Zostaw alert, gdy użytkownik widzi dane kogoś innego, uruchamia skrypt w originie aplikacji albo zmienia stan bez właściwej roli. To jest checklista z części 1. Dostaje defekt ze krokami, nie wklejony identyfikator wtyczki.

Koniec

Jeden baseline obszarów, które zmieniły się w tym sprincie, to pożyteczne popołudnie. Pełny skan aktywny każdego hosta, każdą wtyczką, na każdy pull request sprawia, że raportu nikt nie czyta.

Zapisz hosty w zakresie. Gdy raport dla nich jest przejrzany, skończ. Więcej wtyczek nie domknie roboty, którą dał już pierwszy raport.

Podsumowanie

ZAP daje listę, której nie napisałbyś ręcznie. Nadal ty decydujesz, co jest w aplikacji, a co jest szumem. Następna część serii to kontrola dostępu, którą skaner zwykle pomija, bo potrzebuje dwóch użytkowników i identyfikatora obiektu.

Zadanie na ten tydzień: Odpal baseline na stagingu, zalogowany. Odtwórz ręcznie jeden alert o wysokiej pewności. Zgłoś go z żądaniem albo zamknij z powodem.

Następny wpis w serii: Część 3 — Kontrola dostępu, której skaner nie złapie.