Test penetracyjny aplikacji webowej i API
Northbridge Commerce — fikcyjna organizacja demonstracyjna
Przeczytaj przed użyciem próbki
To realistyczna demonstracja standardu raportowania Breachroad. Organizacja, systemy, identyfikatory, zapytania i ustalenia są fikcyjne. Dokument nie przedstawia projektu klienta, włamania ani danych produkcyjnych.
Zawartość raportu
- 01Podsumowanie zarządcze
- 02Metryka projektu
- 03Ryzyko i ustalenia
- 04Potwierdzona ścieżka ataku
- 05Plan naprawczy
- 06Szczegółowe ustalenia
- 07Pokrycie i ograniczenia
- 08Plan retestu
- 09Metodyka i źródła
Podsumowanie zarządcze
Ustalić, czy uwierzytelniony klient może przekroczyć granicę tenanta, zmienić stan płatności albo zachować dostęp po zdarzeniu bezpieczeństwa konta.
Test potwierdził dwie luki wysokiego ryzyka. Konto o niskich uprawnieniach mogło odczytać fakturę innego tenanta, a webhook bez podpisu zmieniał stan płatności. Żaden scenariusz nie wymagał uprawnień administracyjnych.
Połączona ścieżka tworzy ryzyko poufności i nadużycia finansowego: dane klienta i faktury przekraczają granicę izolacji, a następnie zaufany stan płatności może zostać zmieniony poza prawidłowym przepływem operatora.
MFA było wymagane dla administratorów, endpointy administracyjne odrzucały role klientów, walidacja uploadu blokowała aktywną treść, a test nie potwierdził SQL injection ani zdalnego wykonania kodu.
Metryka projektu
Testowane systemy
app.example.test · api.example.test · auth.example.test
Jawne wyłączenia
Denial of service, socjotechnika, infrastruktura zewnętrznego operatora płatności i dostęp do danych innych niż syntetyczne rekordy testowe.
Model testu
Test grey-box z użyciem dwóch odizolowanych tenantów klienta oraz testowej roli wsparcia. Konfiguracja zbliżona do produkcyjnej; wyłącznie dane syntetyczne.
Ograniczenia oceny punktowej
Pentest próbkuje uzgodnione ścieżki ataku w określonym czasie. Nie gwarantuje wykrycia każdej podatności ani niezmienności środowiska po zakończeniu prac.
Ryzyko i ustalenia
| ID | Ustalenie | CVSS | Ryzyko | Status |
|---|---|---|---|---|
| BR-01 | Dostęp do faktury innego tenanta przez brak autoryzacji obiektowej | 7.1 | WYSOKIE | OTWARTE |
| BR-02 | Webhook płatności bez podpisu akceptowany przez logikę biznesową | 7.5 | WYSOKIE | OTWARTE |
| BR-03 | Refresh token pozostaje ważny po zmianie hasła | 6.5 | ŚREDNIE | OTWARTE |
| BR-04 | Proces odzyskiwania ujawnia zarejestrowane adresy e-mail | 5.3 | ŚREDNIE | OTWARTE |
| BR-05 | Content Security Policy dopuszcza niebezpieczne skrypty inline | 3.1 | NISKIE | OTWARTE |
| BR-06 | Zdarzenia bezpieczeństwa nie zawierają kontekstu granicy tenanta | — | INFO | OTWARTE |
Potwierdzona ścieżka ataku
Istotne ryzyko jest czytelniejsze jako jedna sekwencja niż jako zestaw niepowiązanych alertów.
- STEP 01Przejęte konto klienta o niskich uprawnieniach
- STEP 02Identyfikator faktury pozyskany z prawidłowego procesu
- STEP 03API nie egzekwuje własności obiektu
- STEP 04Zwrócone dane faktury innego tenanta
- STEP 05Webhook bez podpisu zmienia zaufany stan płatności
Plan naprawczy
0–7 dni
Wymusić autoryzację obiektową przy odczycie faktur. Odrzucać każdy webhook bez poprawnego podpisu przed przetworzeniem danych biznesowych. Przejrzeć logi pod kątem odwołań między tenantami i ruchu webhook bez podpisu.
Do 30 dni
Scentralizować politykę autoryzacji, dodać negatywne testy izolacji tenantów, obrócić sekrety webhooków, unieważniać aktywne sesje po zmianie hasła i odzyskaniu konta oraz ograniczyć zapytania do procesu odzyskiwania.
Do 90 dni
Wprowadzić regresyjne testy bezpieczeństwa do CI, monitorować odmowy granicy tenantów i błędy weryfikacji podpisu oraz powtarzać test po istotnych zmianach tożsamości lub płatności.
Szczegółowe ustalenia
Dostęp do faktury innego tenanta przez brak autoryzacji obiektowej
Wysokie — jedno uwierzytelnione żądanie i identyfikator w poprawnym formacie
Wysoki — ujawnienie danych klienta i rozliczeń poza granicą tenanta
API / Produkt
- Przyczyna źródłowa
- Endpoint weryfikuje sesję i identyfikator faktury, ale nie wiąże obiektu z tenantem uwierzytelnionego użytkownika.
- Zanonimizowany dowód
- GET /v1/invoices/inv_demo_9d3 z <TENANT_A_TOKEN> zwrócił HTTP 200 oraz tenant_id: tenant_demo_b.
- Naprawa
- Egzekwować własność tenanta w warstwie dostępu do danych, domyślnie odrzucać i dodać negatywne testy dla każdej referencji oraz roli.
- Kryteria akceptacji retestu
- Tenant A otrzymuje 404/403 dla każdej trasy faktury Tenanta B; brak różnic metadanych; testy obejmują listę, detal, PDF i eksport.
- Odniesienia
- CWE-639 · OWASP API1:2023 · WSTG-ATHZ-04
Webhook płatności bez podpisu akceptowany przez logikę biznesową
Wysokie — publiczny endpoint nie wymaga poprawnego podpisu operatora
Wysoki — możliwość nadania zaufanego stanu „opłacone” poza przepływem operatora
Płatności / Backend
- Przyczyna źródłowa
- Weryfikacja podpisu uruchamia się tylko wtedy, gdy nagłówek istnieje; brak wartości przechodzi do obsługi zdarzenia.
- Zanonimizowany dowód
- POST /v1/webhooks/payment bez X-Payment-Signature zwrócił HTTP 202 i zmienił status demonstracyjnej faktury na paid.
- Naprawa
- Weryfikować surowe body przed parsowaniem, odrzucać brak lub błąd podpisu, wymusić tolerancję czasu i idempotency oraz obrócić sekret.
- Kryteria akceptacji retestu
- Brakujące, błędne, powtórzone i wygasłe podpisy są odrzucane przed zmianą stanu; poprawne fixture przechodzi tylko raz.
- Odniesienia
- CWE-345 · OWASP API10:2023 · WSTG-BUSL-02
Refresh token pozostaje ważny po zmianie hasła
Średnie — wymaga posiadania wcześniej wydanego refresh tokenu
Wysoki — istniejąca sesja może przetrwać zmianę poświadczeń wykonaną z powodów bezpieczeństwa
Tożsamość
- Przyczyna źródłowa
- Reset hasła zmienia poświadczenie, ale nie zwiększa generacji sesji ani nie unieważnia rodzin refresh tokenów.
- Zanonimizowany dowód
- Token wydany przed resetem uzyskał nowy access token po zakończeniu resetu i wysłaniu powiadomienia do użytkownika.
- Naprawa
- Unieważniać wszystkie rodziny refresh tokenów przy zmianie i odzyskaniu hasła; dodać widoczne zarządzanie sesjami oraz telemetrię zdarzeń.
- Kryteria akceptacji retestu
- Każdy token sprzed resetu jest odrzucany; aktywne sesje wygasają, a zdarzenie zawiera kontekst konta i urządzenia.
- Odniesienia
- CWE-613 · OWASP ASVS V3 · WSTG-SESS-06
Proces odzyskiwania ujawnia zarejestrowane adresy e-mail
Wysokie — zdalne, nieuwierzytelnione i możliwe do automatyzacji
Niski do średniego — ułatwia phishing, credential stuffing i profilowanie prywatności
Tożsamość / UX
- Przyczyna źródłowa
- Treść i czas odpowiedzi różnią się dla zarejestrowanego i nieznanego adresu.
- Zanonimizowany dowód
- Znany adres zwrócił metadane kanału odzyskiwania; nieznany — odmienny kod i długość odpowiedzi.
- Naprawa
- Zwracać jeden komunikat, wyrównać obsługę, ograniczyć częstotliwość i wykrywać wzorce enumeracji.
- Kryteria akceptacji retestu
- Znane i nieznane konta mają równoważny status, strukturę body i praktyczny rozkład czasu.
- Odniesienia
- CWE-204 · OWASP ASVS V2 · WSTG-IDNT-04
Content Security Policy dopuszcza niebezpieczne skrypty inline
Niskie — test nie potwierdził niezależnego punktu injection
Niski samodzielnie — osłabienie warstwy ochronnej przy przyszłym błędzie injection
Frontend
- Przyczyna źródłowa
- Polityka produkcyjna zawiera unsafe-inline bez nonce lub hashy.
- Zanonimizowany dowód
- Content-Security-Policy zawiera script-src self unsafe-inline; próbkowane strony nie używają nonce.
- Naprawa
- Przenieść kod inline do zasobów statycznych, wdrożyć nonce lub hashe i najpierw uruchomić ostrzejszą politykę w report-only.
- Kryteria akceptacji retestu
- Brak unsafe-inline; wszystkie przepływy działają z wymuszoną CSP, a naruszenia są monitorowane.
- Odniesienia
- CWE-693 · OWASP Secure Headers Project
Zdarzenia bezpieczeństwa nie zawierają kontekstu granicy tenanta
Luka operacyjna
Wolniejsze dochodzenie i słabszy materiał dowodowy przy podejrzeniu ruchu między tenantami
Platforma / SOC
- Przyczyna źródłowa
- Logi aplikacji zapisują trasę i użytkownika, ale nie właściciela obiektu, tenant docelowy ani decyzję autoryzacji.
- Zanonimizowany dowód
- Nie można było skorelować zdarzeń faktur jednocześnie z tenantem aktora i właściciela obiektu.
- Naprawa
- Logować tenant aktora i celu, typ obiektu, decyzję i trace ID bez danych wrażliwych; alarmować przy próbie niedopasowania.
- Kryteria akceptacji retestu
- Kontrolowane odrzucone żądanie tworzy pełne, wyszukiwalne zdarzenie i uzgodniony sygnał detekcji.
- Odniesienia
- OWASP ASVS V7 · NIST SP 800-92
Macierz pokrycia
| Obszar | Wynik | Uwagi |
|---|---|---|
| Uwierzytelnianie i odzyskiwanie | CZĘŚCIOWO | Potwierdzono problem cyklu sesji; MFA i jednorazowość tokenu resetu zadziałały. |
| Autoryzacja i tenanty | NIEZALICZONE | Potwierdzono brak autoryzacji obiektowej przy pobieraniu faktury. |
| Logika biznesowa i płatności | NIEZALICZONE | Aplikacja przyjmowała webhook bez podpisu. |
| Obsługa danych wejściowych | ZALICZONE | W testowanych ścieżkach nie potwierdzono użytecznego injection. |
| Pliki i integracje | ZALICZONE | Ograniczenia uploadu i callbacków zadziałały w próbkowanych przypadkach. |
| Logowanie i detekcja | CZĘŚCIOWO | Zdarzenia istniały, lecz brakowało kontekstu granicy tenanta i błędów podpisu. |
Plan retestu
Retest powinien użyć pierwotnych żądań oraz dwóch odizolowanych tenantów. Zamknięcie wymaga serwerowej kontroli własności na każdej trasie faktur, weryfikacji podpisu fail-closed przed obsługą webhooku, testu unieważniania sesji i pokrycia regresyjnego. Sama zmiana kodu nie oznacza zamknięcia.
Metodyka i źródła
CVSS v3.1 + business context
Ryzyko łączy wykazany wpływ biznesowy i warunki wykorzystania. CVSS v3.1 jest przejrzystym odniesieniem technicznym, ale nie zastępuje kontekstu środowiska. Każdy wynik liczbowy ma podany wektor.
OWASP · PTES · NIST
Struktura próbki korzysta z zaleceń raportowania OWASP WSTG, kryteriów PTES i NIST SP 800-115. Identyfikatory, dowody, komponenty, naprawa oraz kryteria retestu zachowują pełną śledzalność.