E-usługa dla obywatela.
Od załącznika do konta urzędnika.
Jak test formularza, obiegu dokumentów i panelu pracownika ujawnił łańcuch: niewłaściwa walidacja pliku, niebezpieczny podgląd, brak separacji ról i niedostateczne logowanie.
Bezpieczny formularz kończy się dopiero w panelu obsługi
W skrócie: zbiorczy scenariusz z autoryzowanych testów e-usług pokazał, że załącznik przesłany przez obywatela był przetwarzany inaczej w panelu pracownika niż przy wysyłce. Połączenie niespójnej walidacji, aktywnego podglądu dokumentu i nadmiarowej roli umożliwiało przejęcie sesji testowego konta urzędnika i dostęp do syntetycznych spraw spoza przydzielonej jednostki.
- Ryzyko: naruszenie poufności spraw, podszycie się pod pracownika i utrata rozliczalności.
- Test: bez używania danych obywateli; przygotowane konta, sprawy i dokumenty testowe.
- Rezultat: jednolita walidacja, izolowany podgląd, poprawiona macierz ról i korelacja logów.
Autor: Michał Błaszczak · · BSTA sp. z o.o.
testu
CVSS
uprawnienia
audytowy
Mechanizm jest prawdziwy, środowisko nieidentyfikowalne
Opis łączy powtarzalne mechanizmy z kilku testów. Nazwa urzędu, dostawcy, systemu, role, rozszerzenia plików, endpointy i dane zostały usunięte albo zmienione. Case study nie wskazuje jednego klienta i nie ujawnia działającej ścieżki ataku.
Różne komponenty stosowały różne zasady bezpieczeństwa
Macierz CVSS i STRIDE
Załącznik był renderowany w kontekście pozwalającym wpłynąć na sesję użytkownika panelu. Ryzyko wynikało z różnicy pomiędzy walidacją przy przesyłaniu i przy podglądzie.
Rola operacyjna mogła wywołać funkcję przeznaczoną dla innej jednostki, mimo że interfejs jej nie pokazywał.
Nie wszystkie operacje dało się jednoznacznie powiązać ze sprawą, dokumentem, użytkownikiem i źródłem żądania.
Rekomendacje dla właściciela e-usługi
- Jedna polityka walidacji dla uploadu, magazynu, konwersji, pobierania i podglądu.
- Konwersja do bezpiecznego formatu i izolowany renderer bez dostępu do sesji panelu.
- Autoryzacja każdej funkcji i obiektu po stronie backendu, niezależnie od widoczności w UI.
- Macierz ról oparta na jednostce, zadaniu i minimalnym zakresie spraw.
- Centralne logowanie zdarzeń bezpieczeństwa i korelacja w SIEM.
Co obejmował pentest e-usługi administracji publicznej
Badanie potraktowało portal mieszkańca, elektroniczny formularz, API, moduł załączników i panel urzędnika jako jeden proces. Taki zakres jest istotny, ponieważ bezpieczeństwo e-usługi nie kończy się na publicznej stronie WWW. Żądanie przechodzi przez bramę API, system obiegu dokumentów, magazyn plików, mechanizm podglądu oraz warstwę tożsamości i uprawnień. Błąd na granicy dwóch komponentów może mieć większe znaczenie niż luka widoczna w pojedynczym module.
W uzgodnionym środowisku testowym sprawdziliśmy uwierzytelnianie, odzyskiwanie dostępu, zarządzanie sesją, SSO, autoryzację obiektową i funkcyjną, obsługę plików, walidację danych, komunikację z usługami wewnętrznymi oraz rejestrowanie zdarzeń. Test penetracyjny aplikacji webowej i API prowadziliśmy ręcznie, wspierając się automatyzacją tam, gdzie pomagała wykryć warianty tego samego problemu.
- kanał publiczny: formularze, załączniki, konta mieszkańców i mechanizmy antyautomatyzacyjne;
- API: identyfikatory spraw, dokumentów i jednostek, kontrola ról oraz limity operacji;
- panel pracownika: podgląd dokumentów, wyszukiwanie, eksporty i działania uprzywilejowane;
- tożsamość: SSO, wygaszanie sesji, MFA, role urzędników i konta techniczne;
- monitoring: kompletność logów, korelacja zdarzeń i materiał dla SOC/SIEM.
Jak wykonujemy audyt bezpieczeństwa portalu mieszkańca, API i panelu urzędnika
Scenariusze testowe budujemy na podstawie rzeczywistych ról i przepływów biznesowych, a nie wyłącznie listy endpointów. W tym przypadku osobno modelowaliśmy mieszkańca, pełnomocnika, operatora pierwszej linii, pracownika jednostki, administratora i konto integracyjne. Następnie weryfikowaliśmy, czy każda operacja jest dozwolona nie tylko dla właściwej roli, ale również dla właściwej sprawy, jednostki i etapu procesu.
Zakres techniczny mapowaliśmy do OWASP ASVS i OWASP API Security Top 10. Obejmował on między innymi Broken Object Level Authorization (BOLA/IDOR), Broken Function Level Authorization, błędy kontroli dostępu, niewłaściwe zarządzanie sesją, server-side request forgery, podatności uploadu, XSS, CSRF, błędy konfiguracji oraz nadmierną ekspozycję danych. Ocena uwzględniała CVSS, model STRIDE oraz kontekst biznesowy administracji publicznej.
Skaner może wskazać brak nagłówka lub znaną wersję komponentu, ale nie rozumie, że operator jednej jednostki nie powinien otworzyć sprawy innej jednostki. BOLA, IDOR i błędy procesu wymagają ręcznego porównywania ról, obiektów oraz odpowiedzi backendu.
Jak powstał łańcuch od załącznika do konta pracownika
Pierwsze zachowanie nie wyglądało krytycznie: formularz odrzucał część niedozwolonych plików. Dalsza analiza wykazała jednak, że kontrola rozszerzenia, typu MIME i zawartości nie była jednakowa w każdym komponencie. Plik zaakceptowany przez warstwę wejściową przechodził do usługi podglądu, która renderowała go w innym kontekście bezpieczeństwa.
Bezpieczny dowód koncepcji wykonaliśmy na kontrolowanym koncie i syntetycznej sprawie. Nie odczytywaliśmy danych obywateli. Potwierdziliśmy jedynie, że aktywna zawartość może oddziaływać na sesję testowego operatora. Następnie, już z perspektywy tej roli, sprawdziliśmy egzekwowanie uprawnień po stronie API. Interfejs ukrywał funkcje spoza jednostki, lecz backend nie we wszystkich miejscach weryfikował pełny kontekst organizacyjny.
Łańcuch był ważniejszy od pojedynczego CVSS: niespójna walidacja umożliwiała wejście do kontekstu panelu, zbyt szeroka funkcja rozszerzała zasięg konta, a niepełne logowanie utrudniało szybkie odtworzenie zdarzenia. W raporcie rozdzieliliśmy przyczynę techniczną, warunki wykorzystania, bezpieczny PoC, wpływ na proces urzędowy i kolejność napraw.
Priorytety 24 godziny, 30 dni i 90 dni
Natychmiast: ograniczenie ekspozycji
Wyłączenie aktywnego renderowania, wymuszenie pobierania ryzykownych formatów, zawężenie uprawnień roli oraz dodanie alarmów dla nietypowego dostępu do spraw ograniczały najbardziej prawdopodobne skutki przed wydaniem docelowej poprawki.
Do 30 dni: naprawa kontroli technicznych
Rekomendowaliśmy centralną usługę autoryzacji, walidację właściciela i jednostki dla każdego obiektu, ponowne kodowanie bezpiecznych formatów, osobną domenę podglądu bez dostępu do sesji oraz testy regresyjne dla macierzy ról. Każda reguła została przypisana do właściciela po stronie aplikacji, IAM albo infrastruktury.
Do 90 dni: odporność procesu
Długofalowo warto utrzymywać katalog przepływów danych, jednolity standard bezpiecznego uploadu, przegląd kont uprzywilejowanych, scenariusze detekcyjne w SIEM i cykliczny retest po większych zmianach e-usługi. Dzięki temu wynik pentestu staje się elementem zarządzania ryzykiem, a nie jednorazową listą błędów.
Kiedy zamówić test penetracyjny e-usługi publicznej
Pentest portalu mieszkańca, systemu e-usług lub aplikacji urzędowej warto przeprowadzić przed uruchomieniem produkcyjnym, po zmianie dostawcy SSO, po wdrożeniu nowego obiegu dokumentów, po integracji z zewnętrznym rejestrem oraz przed istotnym audytem. Test jest szczególnie potrzebny, gdy system przetwarza dokumenty, dane osobowe, decyzje administracyjne albo obsługuje wiele jednostek w jednej instancji.
W zapytaniu ofertowym warto opisać adresy środowiska, liczbę ról, główne procesy, API i integracje, rodzaje załączników oraz ograniczenia dostępności. BSTA może podpisać NDA, pracować na danych syntetycznych i uzgodnić bezpieczne okna testowe. Raport przygotowujemy dla zespołu technicznego i kierownictwa, a jedno podejście retestowe jest zazwyczaj w cenie, o ile oferta nie stanowi inaczej.
Zobacz także: testy penetracyjne aplikacji webowych, pentest API, SOC/SIEM i monitoring bezpieczeństwa oraz cennik testów penetracyjnych.
Najczęstsze pytania o pentest e-usługi i systemu urzędowego
Czy pentest może zakłócić działanie e-usługi?
Zakres, limity i momenty wykonywania testów uzgadniamy w Rules of Engagement. Scenariusze mogące wpłynąć na dostępność są wykonywane wyłącznie po zatwierdzeniu albo zastępowane bezpiecznym dowodem wpływu.
Czy trzeba używać prawdziwych danych obywateli?
Nie. Do weryfikacji autoryzacji, obiegu spraw i uploadu zwykle wystarczają przygotowane konta, syntetyczne dokumenty i kontrolowane rekordy testowe. Minimalizacja dostępu do danych produkcyjnych jest częścią planu badania.
Czym różni się BOLA lub IDOR od błędu roli?
BOLA/IDOR dotyczy dostępu do konkretnego obiektu, na przykład cudzej sprawy po zmianie identyfikatora. Błąd autoryzacji funkcyjnej pozwala uruchomić całą funkcję przeznaczoną dla innej roli. W rozbudowanej e-usłudze oba problemy mogą wystąpić jednocześnie.
Czy test obejmuje SSO i logowanie urzędników?
Tak, jeśli elementy te znajdują się w uzgodnionym zakresie. Weryfikujemy przepływy logowania, sesje, MFA, wylogowanie, mapowanie ról, obsługę błędów i zaufanie pomiędzy dostawcą tożsamości a aplikacją.
Co powinien zawierać raport z pentestu dla JST lub urzędu?
Raport powinien zawierać podsumowanie zarządcze, zakres i ograniczenia, opis metodyki, ocenę ryzyka, techniczny dowód, wpływ biznesowy, zalecenia, priorytet naprawy oraz załącznik z wynikami retestu. Ważna jest też jednoznaczna informacja, których komponentów nie badano.
Czy pentest zastępuje audyt KRI albo audyt zgodności?
Nie. Pentest dostarcza technicznego dowodu skuteczności lub nieskuteczności zabezpieczeń, natomiast pełny audyt obejmuje również organizację, procesy, dokumentację i zarządzanie ryzykiem. Oba działania mogą się uzupełniać.
Ile trwa test penetracyjny e-usługi?
Realizacja testu zajmuje od 5 dni roboczych. Czas zależy od liczby ról, procesów, API, integracji i ograniczeń środowiska, a ostateczny termin potwierdza oferta.
Czy po poprawkach wykonujecie retest?
Tak. Jedno podejście retestowe jest zazwyczaj w cenie, o ile oferta nie stanowi inaczej. Weryfikujemy nie tylko zamknięcie konkretnego przypadku, ale również ryzyko regresji w podobnych operacjach.
Test techniczny uzupełnia audyt bezpieczeństwa informacji
Podmioty realizujące zadania publiczne podlegają wymaganiom KRI, w tym okresowemu audytowi bezpieczeństwa informacji. Nowelizacja KSC obejmuje również szeroki katalog podmiotów publicznych. Pentest nie zastępuje całego audytu organizacyjnego, lecz sprawdza w praktyce skuteczność kontroli technicznych.
Źródła: Portal Interoperacyjności i Architektury — KRI, Ministerstwo Cyfryzacji — KSC i OWASP ASVS.
Chcesz zweryfikować e-usługę przed audytem albo uruchomieniem?
Testujemy formularze, dokumenty, API, role, SSO, integracje i infrastrukturę z kontrolą wpływu na dostępność.
Ustal bezpieczny zakres →