'/%3E%3C/svg%3E){kind=small}
Testy penetracyjne aplikacji desktop
Testy penetracyjne aplikacji desktop (thick client) od 9 999 zł netto: reverse engineering, fuzzing, analiza pamięci, kryptografii i komunikacji z API według OWASP ASVS. Raport z oceną CVSS, retest do 30 dni i platforma vulnerability management w cenie.
- Certyfikowani pentesterzy (OSCP, OSWE, OSEP)
- Retest do 30 dni w cenie
- Wgląd w postęp testów w platformie vulnerability management
- .NET 6 · 214 klas · 3 sekrety w stałych
- %APPDATA%\Klient\session.txt · brak szyfrowania
- WysokaSekrety zaszyte w binarce (.NET)
- WysokaToken sesji w pliku tekstowym
- ŚredniaAktualizator bez weryfikacji podpisu
- OKHasło użytkownika chronione DPAPI
- 214klas przeanalizowanych
- 8znalezisk
- 2wysokie
Testy penetracyjne aplikacji desktop (thick client) od 9 999 zł netto sprawdzają, co atakujący może zrobić z programem zainstalowanym na komputerze użytkownika: odczytać zapisane hasła i tokeny, podsłuchać komunikację z backendem, zmodyfikować binaria, ominąć licencję lub wykorzystać aplikację do przejęcia systemu operacyjnego. Wycena po rozmowie o zakresie, bo cena zależy od liczby modułów, technologii i tego, czy w zakresie jest również API.
Testy bezpieczeństwa aplikacji desktopowych realizujemy w oparciu o połączenie manualnej analizy eksperckiej oraz automatyzowanych testów bezpieczeństwa, z zastosowaniem narzędzi i technik dostosowanych do architektury konkretnej aplikacji: .NET (C#, WPF, WinForms), C++, Java, Electron, Qt, Delphi i inne, na Windows, a także na macOS i Linux dla aplikacji wieloplatformowych. Badania obejmują zarówno analizę statyczną kodu i komponentów aplikacji, jak i dynamiczną analizę działania aplikacji w czasie rzeczywistym, w celu identyfikacji potencjalnych podatności, błędów implementacyjnych oraz słabości w integracji z systemem operacyjnym lub siecią.
Analizowane obszary aplikacji
Analiza binarna, pamięć procesu, komunikacja klient–serwer i uprawnienia lokalne: gruby klient to trzy powierzchnie ataku naraz (plik na dysku, proces w pamięci, połączenie z serwerem). W ramach testów analizujemy każdą z nich.
Architektura i konfiguracja aplikacji
Ocena struktury komponentów i ich wzajemnych interakcji oraz analiza plików konfiguracyjnych, manifestów, parametrów uruchamiania i mechanizmów aktualizacji, które często pozwalają podmienić kod aplikacji (zobacz: przejęcie aktualizacji Notepad++ – ryzyko dla aplikacji desktop).
Przechowywanie danych i kryptografia
Identyfikacja niezaszyfrowanych danych, informacji poufnych oraz ich lokalizacji (pliki tymczasowe, cache, rejestr), poprawność stosowanych algorytmów, zarządzanie kluczami i magazynowanie sekretów.
Uwierzytelnianie i zarządzanie sesją
Odporność aplikacji na ataki związane z przejęciem sesji, ponownym użyciem tokenów, zapisanymi na stałe poświadczeniami (hardcoded credentials) i obejściem logowania po stronie klienta.
Komunikacja sieciowa i API
Weryfikacja bezpieczeństwa protokołów, transmisji danych i odporności na ataki MITM. Jeśli aplikacja typu thick client komunikuje się z usługą API, również ona zostaje poddana kompleksowej analizie zgodnie z OWASP ASVS i praktykami stosowanymi w testach API/web services (REST, SOAP, RPC): autoryzacja, manipulacja danymi, walidacja wejść.
Interakcja z systemem operacyjnym
Testy uprawnień, odczytu i zapisu do katalogów systemowych, interfejsów IPC, usług systemowych i kluczy rejestru. Sprawdzamy, czy aplikacja uruchamiana przez zwykłego użytkownika nie daje mu uprawnień administratora.
Zabezpieczenia przed inżynierią wsteczną
Detekcja obfuskacji, mechanizmów anty-debugging i ochrony przed manipulacją kodem. Oceniamy, ile wysiłku wymaga odtworzenie logiki, ominięcie licencji lub wstrzyknięcie własnego kodu do procesu.
Metodyka: OWASP, MITRE CWE i PTES
Testy przeprowadzamy zgodnie z uznanymi metodykami i najlepszymi praktykami branżowymi, łącząc analizę statyczną binariów z dynamiczną obserwacją działającego procesu.
Techniki analizy statycznej i reverse engineering
- Testy statyczne – analiza binariów pod kątem słabości kodu, hardcoded credentials, niezałatanych bibliotek
- Reverse engineering – deasemblacja i analiza kodu w celu identyfikacji mechanizmów działania oraz ukrytych funkcji
- Weryfikacja bezpieczeństwa kryptografii – poprawność implementacji algorytmów szyfrowania i zarządzania kluczami
- Testy komponentów przechowywanych na systemie operacyjnym – pliki, konfiguracja i lokalizacje, w których aplikacja zapisuje dane (pliki tymczasowe, cache, konfiguracja)
- Przegląd kluczy rejestru (Windows) – zapisy konfiguracyjne i miejsca przechowywania danych uwierzytelniających
- Analiza logów i przechowywanych danych – identyfikacja możliwego wycieku danych lub zapisów wrażliwych informacji
Techniki analizy dynamicznej i fuzzing
- Fuzzing – automatyczne testowanie komponentów aplikacji nieprawidłowymi lub losowymi danymi wejściowymi, aby wykryć błędy wykonania (crashe, wyjątki)
- Testy dynamiczne – monitorowanie działania aplikacji w czasie rzeczywistym: interakcja z systemem operacyjnym, API, plikami i siecią
- Analiza komponentów sieciowych i API – połączenia wychodzące i komunikacja z backendem, bezpieczeństwo endpointów, uwierzytelnienie i autoryzacja
- Wstrzyknięcia (Injections) – SQL, OS Command, XML, DLL
- Monitorowanie procesów i pamięci (memory inspection) – obecność wrażliwych danych w pamięci operacyjnej (hasła, tokeny)
Wykorzystywane standardy i metodyki
- OWASP Application Security Verification Standard (ASVS) – główna rama odniesienia dla weryfikacji bezpieczeństwa aplikacji typu thick client
- OWASP Testing Guide – metodologia ogólna i klasyfikacja testów
- OWASP Desktop Application Security Cheat Sheet – źródło technicznych zaleceń i testów kontrolnych
- MITRE CWE – klasyfikacja wykrytych podatności
- PTES – wspólny szkielet procesu dla wszystkich testów penetracyjnych VIPentest
Przykładowe narzędzia wykorzystywane podczas testów
- Burp Suite Professional – testy API i komunikacji sieciowej
- Process Monitor / Process Hacker – analiza procesów i interakcji z OS
- x64dbg / Ghidra / IDA Pro – debugowanie, reverse engineering
- Wireshark / Fiddler – analiza ruchu sieciowego
- Sysinternals Suite – monitorowanie aktywności rejestru, plików, pamięci
- Dependency Walker / PEStudio – analiza komponentów aplikacji
- Własne skrypty (Python, PowerShell) – automatyzacja eksploracji i eksploitacji
Jak przebiega test aplikacji desktop krok po kroku
Ten sam proces co przy pozostałych testach VIPentest, z jedną różnicą: zamiast adresu URL potrzebujemy instalatora i środowiska, w którym aplikacja działa tak jak u Twoich użytkowników.
- 01
Rozmowa o zakresie
Ustalamy technologię aplikacji, liczbę modułów, sposób logowania, czy w zakresie jest backend/API i czy pracujemy w modelu grey box (instalator i konta testowe) czy white box (z dostępem do kodu źródłowego). Po rozmowie dostajesz wycenę z konkretną liczbą dni.
- 02
Formalności
Umowa i NDA elektronicznie, konta testowe dla każdej roli, instalator lub obraz środowiska, osoba kontaktowa i ścieżka eskalacji przy podatności krytycznej.
- 03
Rekonesans i modelowanie zagrożeń
Mapujemy architekturę: komponenty, pliki, procesy, połączenia sieciowe, uprawnienia. Ustalamy, co dla Twojego biznesu byłoby najgorszym scenariuszem (wyciek danych klientów, ominięcie licencji, przejęcie stacji), i od tego zaczynamy.
- 04
Analiza statyczna i dynamiczna
Reverse engineering binariów, fuzzing wejść, inspekcja pamięci, testy komunikacji z API, wstrzyknięcia, kryptografia i interakcja z systemem operacyjnym. Każdą podatność widzisz w platformie vulnerability management w dniu wykrycia, o krytycznych informujemy dodatkowo telefonicznie.
- 05
Raport i spotkanie omawiające
Streszczenie zarządcze, lista podatności z oceną CVSS i CWE, dowody krok po kroku, rekomendacje w kolejności wdrożenia. Omawiamy je z Twoimi deweloperami.
- 06
Retest w cenie
Po wydaniu poprawionej wersji zgłaszasz poprawki w platformie jednym kliknięciem, a my sprawdzamy, czy podatności zniknęły, i wystawiamy raport końcowy z certyfikatem.
Cennik testów penetracyjnych aplikacji desktop
Pentest aplikacji desktop: cena zależy od zakresu, dlatego podajemy próg „od” i typowe czasy realizacji, a dokładną kwotę po rozmowie.
Od 9 999 zł netto. Wycena po rozmowie o zakresie: cena zależy od liczby modułów i ekranów aplikacji, technologii (natywna, .NET, Java, Electron), liczby ról użytkownika, obecności backendu lub API w zakresie oraz modelu testu (grey box lub white box z dostępem do kodu). Typowe czasy realizacji: prosta aplikacja lokalna 4–5 dni roboczych, aplikacja kliencka z backendem/API 5–7 dni, system wielomodułowy lub produkcyjny 10+ dni.
Zawsze w cenie:
- raport w dwóch wersjach: zarządczej i technicznej, z oceną CVSS, dowodami i rekomendacjami
- retest do 30 dni od przekazania raportu oraz raport końcowy z certyfikatem
- dostęp do platformy vulnerability management VIPentest w trakcie testu i po nim
- konsultacja z pentesterem po teście, spotkanie omawiające z zespołem deweloperskim
Jeśli ta sama logika biznesowa jest dostępna także w przeglądarce, zwykle taniej jest połączyć test grubego klienta z testami penetracyjnymi aplikacji webowych i API w jednym projekcie. Porównanie wszystkich rodzajów testów znajdziesz na stronie rodzaje testów penetracyjnych.
Co dostajesz w raporcie z testu aplikacji desktop
Po zakończeniu testów dostarczamy szczegółowy raport, który czytają dwie różne osoby: zarząd i deweloper.
Raportowanie
- Zidentyfikowane podatności sklasyfikowane według poziomu istotności (Krytyczne, Wysokie, Średnie, Niskie oraz Informacyjne), co umożliwia szybkie zrozumienie priorytetów i zakresu ryzyk dla organizacji.
- Techniczny i biznesowy opis każdego problemu.
- Przypisany poziom ryzyka zgodny z uznanymi standardami (CVSS).
- Możliwe skutki wykorzystania podatności przez osoby niepowołane.
- Kroki umożliwiające odtworzenie podatności: zrzuty ekranu, komendy, payloady, logi, fragmenty zdeasemblowanego kodu.
- Identyfikator CWE ułatwiający klasyfikację problemu w międzynarodowych rejestrach.
- Odnośniki do źródeł zewnętrznych (OWASP, MITRE, CVE) pozwalające zweryfikować podatność lub zgłębić temat.
- Zalecenia mitygacji ryzyk dopasowane do kontekstu organizacji i środowiska: konfiguracja, aktualizacje komponentów, zmiany w logice aplikacji, ograniczenia dostępu, mechanizmy detekcji i monitorowania.
Wgląd w test w platformie vulnerability management
Każdy klient dostaje dostęp do platformy vulnerability management VIPentest na czas testu i po nim: widzisz postęp testu, każda podatność pojawia się w dniu wykrycia z oceną CVSS, dowodem i rekomendacją, a po wydaniu poprawionej wersji zgłaszasz ją do retestu jednym kliknięciem. Raport i certyfikat pobierasz z tej samej platformy.
W raporcie opisujemy też zakres, model testu, użyte narzędzia i wyłączenia, tak by dokument nadawał się dla audytora ISO 27001 lub klienta, który wymaga od Ciebie testu bezpieczeństwa oprogramowania.
Dla kogo: producenci oprogramowania, medycyna, przemysł, finanse
Testy aplikacji klient-serwer zamawiają najczęściej firmy, których oprogramowanie trafia na komputery klientów, pacjentów, operatorów maszyn lub pracowników banków.
Typowe sytuacje
- Tworzysz oprogramowanie instalowane u klientów (ERP, systemy medyczne, bankowe, przemysłowe, POS) i klient lub regulator wymaga raportu z testu.
- Aplikacja przechowuje lokalnie dane osobowe, klucze lub tokeny i chcesz wiedzieć, czy ktoś z dostępem do komputera je odczyta.
- Model licencyjny lub logika biznesowa siedzi po stronie klienta i musisz sprawdzić, jak łatwo ją obejść.
- Aplikacja działa z podwyższonymi uprawnieniami lub instaluje usługę systemową, więc jej błąd oznacza przejęcie stacji roboczej.
Powiązane usługi
- Testy penetracyjne aplikacji mobilnych, gdy ten sam backend obsługuje również aplikację iOS lub Android.
- Testy penetracyjne infrastruktury, jeśli aplikacja jest wdrażana na serwerach terminalowych lub w sieci wewnętrznej firmy.
- Audyt konfiguracji i hardening stacji roboczych, na których działa aplikacja; o tym, jak stacje przejmuje się bez luki w aplikacji, piszemy w artykule złośliwe rozszerzenia jako zagrożenie dla stacji roboczych.
Jak przygotować aplikację desktop do testu
Kilka rzeczy przygotowanych przed startem skraca test i pozwala pentesterowi od pierwszego dnia pracować na właściwej wersji.
- Instalator i wersja. Dokładnie ta wersja aplikacji, która trafia do użytkowników, wraz z wymaganymi bibliotekami i licencją testową.
- Środowisko testowe backendu. Serwer lub API, do którego aplikacja może się łączyć bez ryzyka dla danych produkcyjnych.
- Konta testowe. Po jednym na każdą rolę użytkownika (np. operator, administrator), z danymi, które można bezpiecznie modyfikować.
- Dokumentacja. Opis architektury, protokołów komunikacji i mechanizmu aktualizacji; dla white box dostęp do repozytorium kodu.
- Zgody dostawców. Jeśli backend stoi w chmurze lub u hostingodawcy, część z nich wymaga zgłoszenia testu z wyprzedzeniem.
- Osoba kontaktowa i ścieżka eskalacji. Kto odbiera telefon, gdy znajdziemy podatność krytyczną.
Uwagi końcowe
VIPentest Sp. z o.o. zastrzega sobie prawo do modyfikacji planu testów w zależności od bieżących potrzeb i ustaleń z klientem. Zakres, model testu i lista komponentów wyłączonych z analizy są zawsze potwierdzane pisemnie przed rozpoczęciem prac.
Najczęściej zadawane pytania
Czym są testy penetracyjne aplikacji desktopowych?
Testy penetracyjne aplikacji desktopowych to symulowany atak hakerski na oprogramowanie zainstalowane lokalnie w systemie użytkownika, mający na celu wykrycie luk bezpieczeństwa w logice aplikacji, autoryzacji, komunikacji sieciowej i integracji z systemem operacyjnym. Takie testy pozwalają zidentyfikować realne ryzyka przed wykorzystaniem ich przez cyberprzestępców.
Jakie technologie obejmują testy aplikacji desktopowych?
Testy obejmują aplikacje napisane w: .NET (C#, WPF, WinForms), Java (Swing, JavaFX), Electron, C++, Python (PyQt, Tkinter), Qt, Delphi, GoLang, Rust, a także aplikacje hybrydowe i klienckie komunikujące się z backendem lub API.
Jak przebiega test penetracyjny aplikacji desktopowej?
Proces obejmuje: rozmowę o zakresie i formalności (umowa, NDA, instalator, konta testowe), analizę architektury i wektorów ataku, inżynierię wsteczną (reverse engineering), analizę binarną i dynamiczną (fuzzing, inspekcja pamięci), testy uprawnień i mechanizmów uwierzytelniania, analizę komunikacji sieciowej i szyfrowania oraz raport z rekomendacjami i priorytetami ryzyka, a po wdrożeniu poprawek retest do 30 dni. Test realizowany jest w modelu grey box (instalator i konta testowe) lub white box (z dostępem do kodu źródłowego).
Ile trwa test penetracyjny aplikacji desktopowej?
Zależnie od złożoności projektu: prosta aplikacja lokalna 4–5 dni roboczych, aplikacja kliencka z backendem/API 5–7 dni roboczych, system wielomodułowy lub produkcyjny 10+ dni roboczych. Do tego dochodzą 2–3 dni na raport i spotkanie omawiające. Dokładny harmonogram podajemy w wycenie po rozmowie o zakresie.
Ile kosztuje test penetracyjny aplikacji desktopowej?
Cena testu zaczyna się od 9 999 zł netto dla pojedynczej aplikacji. Przy większych projektach, testach wielomodułowych lub z backendem i API w zakresie koszt rośnie wraz z liczbą modułów, ról użytkownika i technologii. Po analizie środowiska przygotowujemy indywidualną wycenę, dopasowaną do zakresu, ryzyka i wymagań branżowych. W cenie jest raport, retest do 30 dni, dostęp do platformy vulnerability management i konsultacja po teście.
Czy testy aplikacji desktopowych spełniają wymagania NIS2 i DORA?
Tak. Testy penetracyjne aplikacji desktopowych stanowią element zgodności z dyrektywami NIS2 i DORA, które nakazują regularne testowanie systemów IT pod kątem odporności na cyberataki (TLPT / Red Teaming). Raport z testu może być wykorzystany jako dowód zgodności podczas audytu regulacyjnego.
Czy testy są bezpieczne dla środowiska produkcyjnego?
Tak. Wszystkie testy wykonywane są w kontrolowanym środowisku z zachowaniem zasad bezpieczeństwa. Preferujemy, aby testy były przeprowadzone w środowisku testowym (staging) lub w wydzielonej kopii systemu, na kontach testowych z danymi, które można bezpiecznie modyfikować.
Czym jest aplikacja thick client i czym różni się jej test od testu aplikacji webowej?
Thick client (gruby klient) to aplikacja instalowana na komputerze użytkownika, która wykonuje logikę lokalnie i zwykle łączy się z serwerem lub API. W aplikacji webowej cały kod działa po stronie serwera, a tester widzi tylko przeglądarkę. W thick client atakujący ma binaria, pamięć procesu, pliki konfiguracyjne i rejestr, dlatego test obejmuje reverse engineering, fuzzing, inspekcję pamięci, kryptografię i interakcję z systemem operacyjnym, a dodatkowo komunikację z backendem, którą testujemy jak API.
Czy testujecie aplikacje na Windows, macOS i Linux?
Tak. Najczęściej testujemy aplikacje dla Windows napisane w .NET (C#, WPF, WinForms), C++, Delphi lub Qt, gdzie sprawdzamy m.in. klucze rejestru, usługi systemowe i uprawnienia. Aplikacje wieloplatformowe (Java, Electron, Python, Go, Rust) testujemy także na macOS i Linux, w środowisku odpowiadającym Twoim użytkownikom. Potrzebujemy instalatora w wersji, która trafia do klientów, oraz licencji testowej.
Czy do testu aplikacji desktop potrzebny jest kod źródłowy?
Nie. W modelu grey box wystarczy instalator, konta testowe i dostęp do środowiska backendu; analizę statyczną prowadzimy na binariach (deasemblacja, dekompilacja, analiza bibliotek). Jeśli udostępnisz kod źródłowy (white box), test jest dokładniejszy: szybciej znajdujemy błędy w logice, kryptografii i obsłudze danych, a rekomendacje wskazujemy w konkretnych miejscach kodu. Model ustalamy na rozmowie o zakresie i potwierdzamy w umowie.
Czy test obejmuje serwer i bazę danych, z którą łączy się aplikacja?
Tak, jeśli backend jest w zakresie. Jeśli aplikacja komunikuje się z usługą API (REST, SOAP, RPC), poddajemy ją analizie zgodnie z OWASP ASVS i praktykami testów API: uwierzytelnianie, autoryzacja, manipulacja danymi, walidacja wejść oraz to, czy klient nie ma dostępu do funkcji, których nie powinien wywołać. Bazę danych testujemy przez aplikację i API (wstrzyknięcia, nadmiarowe uprawnienia). Pełny test serwerów i sieci zamawia się osobno jako testy penetracyjne infrastruktury.
Czy sprawdzacie mechanizmy licencjonowania i ochronę przed reverse engineeringiem?
Tak. Oceniamy zabezpieczenia przed inżynierią wsteczną: obfuskację, mechanizmy anty-debugging i ochronę przed manipulacją kodem, a także to, ile wysiłku wymaga odtworzenie logiki, ominięcie weryfikacji licencji lub wstrzyknięcie własnego kodu do procesu. Sprawdzamy również, czy klucze licencyjne, sekrety i tokeny nie są zapisane na stałe w binariach, plikach konfiguracyjnych lub rejestrze. Wynik trafia do raportu z oceną ryzyka i rekomendacjami dla zespołu deweloperskiego.
Co mówią klienci
WojtekKlient VIPentest★★★★★Ze względu na wymagania regulacyjne musieliśmy przeprowadzić testy bezpieczeństwa znanego produktu third-party - w tym przypadku była to aplikacja desktopowa rozwijana przez dużą, międzynarodową korporację.
Ku naszemu zdumieniu, mimo renomy producenta, testy wykazały kilka istotnych problemów - od nieoptymalnych ustawień po podatności, które w odpowiednich warunkach mogłyby zostać wykorzystane. Dzięki Vipentest udało się szybko je zidentyfikować i przekazać dostawcy odpowiednie informacje.
Powiązane usługi
Sprawdź, ile kosztuje test w Twoim zakresie
Opisz aplikację, system lub organizację w krótkim formularzu. Oddzwonimy tego samego dnia z wyceną i planem testów. Bez zobowiązań, z NDA przed rozmową.
- Potwierdzenie zgłoszeniaOdpisujemy w ciągu 24 h w dni robocze i dopytujemy o zakres.
- Rozmowa o zakresie pod NDAUstalamy cele, środowisko, terminy i sposób dostępu.
- Wycena i plan testówZwykle tego samego dnia po rozmowie. Bez zobowiązań.
- Retest do 30 dni w cenie
- Raport gotowy dla audytora
- Platforma vulnerability management
Napisz do nas: bezpłatna wycena i konsultacja zakresu
Opisz krótko, co chcesz przetestować (aplikację, system, organizację). Odpowiadamy w ciągu jednego dnia roboczego.
