Portal pacjenta i API.
Jedno konto nie może oznaczać dostępu do cudzej dokumentacji.

Błąd autoryzacji pozwalał wyjść poza kartę własnego pacjenta

W skrócie: w scenariuszu zbudowanym z powtarzalnych mechanizmów obserwowanych podczas autoryzowanych testów systemów medycznych połączenie BOLA, zbyt szerokiej roli integracyjnej i przewidywalnego procesu eksportu umożliwiało dostęp do dokumentu przypisanego do innego profilu. Wszystkie próby wykonano na rekordach testowych.

• Aktywa: dane pacjenta, wyniki, skierowania, załączniki i historia operacji.
• Główne ryzyka: BOLA/IDOR, broken function level authorization, niewłaściwa obsługa linków do dokumentów i słaba separacja integracji.
• Wynik: potwierdzony odczyt syntetycznego dokumentu spoza własnego zakresu oraz plan naprawczy.

Autor: Michał Błaszczak · 29 lipca 2026 · BSTA sp. z o.o.

Materiał nie opisuje jednego podmiotu

To zanonimizowane, zbiorcze case study. Nazwy organizacji, produktów, endpointów, ról, pól danych i wartości zostały usunięte. Zachowane zostały klasy błędów i sposób ich bezpiecznej weryfikacji. Nie publikujemy danych pacjentów ani szczegółów umożliwiających identyfikację wdrożenia.

Macierz pacjent–personel–integracja ujawniła niespójność

Najważniejszym elementem nie była enumeracja samych identyfikatorów, lecz systematyczna macierz testów negatywnych. Każdy endpoint sprawdziliśmy dla innego właściciela rekordu, innej jednostki, roli personelu i kanału integracyjnego.

Od podatności do skutku dla pacjenta i organizacji

Kontrola dostępu musi być spójna w każdym kanale

1. Centralna polityka autoryzacji obiektowej z kontrolą właściciela, jednostki, celu przetwarzania i roli.
2. Testy negatywne dla każdej operacji CRUD oraz eksportu i załączników.
3. Minimalizacja uprawnień kont integracyjnych i rotowane, krótko żyjące poświadczenia.
4. Jednorazowe linki związane z odbiorcą, krótkim TTL i pełnym audytem pobrania.
5. Alerty SIEM dla sekwencyjnej enumeracji identyfikatorów, odmów i nietypowych eksportów.

Pentest portalu pacjenta, aplikacji mobilnej i medycznego API

Bezpieczeństwo systemu ochrony zdrowia ocenialiśmy jako ciąg powiązanych procesów. Portal WWW, aplikacja mobilna, API, integracja z systemem placówki, moduł dokumentów i konta personelu korzystały z tych samych danych, ale nie zawsze z tych samych reguł autoryzacji. Dlatego test jednego interfejsu nie dawał pełnej odpowiedzi.

Sprawdziliśmy uwierzytelnianie, odzyskiwanie konta, MFA, sesje, profile rodzinne i pełnomocnictwa, rejestrację wizyt, recepty, wyniki, dokumenty, wiadomości, eksporty i połączenia integracyjne. Każdy scenariusz wykonywaliśmy na danych syntetycznych i kontach przygotowanych do badania.

• pacjent: dostęp do własnych danych, relacje opiekun–podopieczny i wycofanie zgody;
• personel: role lekarza, rejestracji, laboratorium, administratora i użytkownika tymczasowego;
• API: BOLA/IDOR, BFLA, masowe przypisanie pól, limity, eksporty i załączniki;
• integracje: konta techniczne, zakres tokenów, kolejki, linki do dokumentów i webhooki;
• logowanie: rozliczalność odczytu i zmiany danych oraz alerty dla nietypowego eksportu.

Macierz autoryzacji ważniejsza niż sama lista endpointów

Dla każdego zasobu tworzyliśmy macierz: właściciel rekordu, jednostka medyczna, rola, cel operacji i kanał dostępu. Następnie testowaliśmy scenariusze pozytywne i negatywne. Ważny token nie mógł oznaczać automatycznej zgody na wskazany dokument, wynik albo profil pacjenta.

Testy mapowaliśmy do OWASP ASVS, OWASP API Security Top 10 i OWASP MASVS dla aplikacji mobilnej. Oprócz BOLA/IDOR analizowaliśmy zarządzanie sesją, reset dostępu, przechowywanie danych na urządzeniu, pinning certyfikatu, deep links, SSRF, upload dokumentów, XSS i błędy konfiguracji.

Co oznacza błąd autoryzacji dla pacjenta, placówki i zespołu SOC

Skutkiem BOLA może być ujawnienie wyniku, skierowania, załącznika lub danych kontaktowych. Wpływ nie ogranicza się do poufności: nieprawidłowa autoryzacja operacji zapisu może zmienić dane kliniczne, termin wizyty albo ustawienia komunikacji. Wycena ryzyka uwzględniała wrażliwość rekordu, skalę możliwej enumeracji i łatwość automatyzacji.

Brak pełnego śladu audytowego zwiększa koszt incydentu. Rekomendowaliśmy korelację użytkownika, pacjenta, jednostki, roli, urządzenia i operacji. Dla SOC/SIEM powstały scenariusze wykrywające sekwencyjne identyfikatory, wiele odmów, masowe pobrania, użycie linku z nowego kontekstu oraz aktywność konta integracyjnego poza normalnym profilem.

Raport rozdzielał zalecenia dla zespołu aplikacyjnego, IAM, integracji i monitoringu. Dzięki temu naprawa nie sprowadzała się do dodania pojedynczego warunku w jednym endpointcie.

Kiedy zamówić audyt bezpieczeństwa systemu medycznego

Pentest warto wykonać przed uruchomieniem portalu pacjenta lub aplikacji, po zmianie dostawcy tożsamości, po integracji z nową placówką, laboratorium lub systemem płatności, po dodaniu profili rodzinnych oraz przed istotnym audytem. Badanie jest szczególnie potrzebne, gdy jedna platforma obsługuje wiele placówek albo tenantów.

Do wyceny przydają się: liczba aplikacji i ról, lista głównych procesów, API i integracje, typ danych testowych, wymagania dostępności i możliwość utworzenia kontrolnych rekordów. Możemy podpisać NDA i prowadzić test bez dostępu do rzeczywistych danych pacjentów.

Powiązane usługi: pentest aplikacji webowej, testy aplikacji mobilnych, pentest API od 1 999 zł i SOC/SIEM.

Najczęstsze pytania o pentest systemu ochrony zdrowia

Czy podczas pentestu trzeba udostępniać dane pacjentów?

Nie. Preferujemy konta i rekordy syntetyczne. Jeżeli test produkcyjny wymaga kontaktu z rzeczywistym systemem, zakres i minimalizację dostępu uzgadniamy wcześniej w Rules of Engagement.

Czy sprawdzacie BOLA/IDOR w dokumentacji medycznej?

Tak. Weryfikujemy relację użytkownika z profilem pacjenta, dokumentem, wynikiem, wizytą i załącznikiem dla każdego kanału API, a także role personelu i integracji.

Czy pentest obejmuje aplikację mobilną?

Może obejmować aplikację Android lub iOS, lokalne przechowywanie, komunikację, deep links, WebView, pinning certyfikatu, sesję i zaufanie pomiędzy aplikacją a backendem.

Jak testujecie reset hasła i odzyskiwanie konta?

Sprawdzamy identyfikację użytkownika, ważność i jednokrotność tokenu, ujawnianie informacji, możliwość przejęcia procesu oraz wygaszanie wcześniejszych sesji. Używamy wyłącznie kont testowych.

Czy pentest zastępuje ocenę zgodności lub analizę ryzyka wyrobu medycznego?

Nie. Test penetracyjny dostarcza dowodów technicznych, ale nie zastępuje pełnego audytu organizacyjnego, oceny zgodności ani procesu zarządzania ryzykiem produktu.

Co zawiera raport?

Raport zawiera zakres, ograniczenia, metodykę, podsumowanie zarządcze, CVSS, STRIDE, bezpieczny PoC, wpływ na dane i proces, zalecenia oraz priorytety naprawy. Może być przygotowany po polsku lub angielsku.

Ile trwa pentest portalu pacjenta?

Realizacja testu zajmuje od 5 dni roboczych. Czas zależy od liczby ról, aplikacji, integracji i procesów medycznych, a ostateczny termin potwierdza oferta.

Czy po naprawie otrzymamy retest?

Tak. Jedno podejście retestowe jest zazwyczaj w cenie, o ile oferta nie stanowi inaczej.

Pentest wspiera zgodność, ale nie zastępuje całego audytu

Ochrona zdrowia, producenci produktów leczniczych i wyrobów medycznych należą do sektorów objętych KSC. Dla oprogramowania będącego wyrobem medycznym dochodzą wymagania zarządzania ryzykiem i walidacji wynikające z MDR/IVDR. Zakres obowiązków zależy od podmiotu i produktu; nie należy przedstawiać pentestu jako automatycznie obowiązkowego dla każdej placówki.

Źródła: sektory KSC, MDR 2017/745 i OWASP API Security.