Aplikacje desktopowe nadal odgrywają ważną rolę w wielu organizacjach. Korzystamy z nich w systemach finansowych, medycznych, przemysłowych, administracyjnych, produkcyjnych oraz w wewnętrznych narzędziach firmowych.
Często zakłada się, że aplikacja zainstalowana na komputerze użytkownika jest bezpieczniejsza niż aplikacja webowa, ponieważ nie jest bezpośrednio dostępna przez przeglądarkę. To jednak bardzo mylące podejście.
Aplikacja desktopowa może:
- przetwarzać dane wrażliwe,
- komunikować się z API i bazami danych,
- przechowywać tokeny oraz hasła,
- wykonywać polecenia systemowe,
- korzystać z bibliotek zewnętrznych,
- zapisywać dane w plikach i rejestrze systemowym,
- działać z podwyższonymi uprawnieniami,
- instalować usługi działające w tle,
- pobierać oraz instalować aktualizacje.
Atakujący może analizować pliki wykonywalne, biblioteki, konfigurację, ruch sieciowy, pamięć procesu, lokalne pliki, wpisy w rejestrze oraz sposób komunikowania się aplikacji z innymi systemami.
OWASP Desktop App Security Top 10 porządkuje najważniejsze zagrożenia dotyczące aplikacji desktopowych i tzw. thick clientów. Najnowsza opublikowana wersja listy pochodzi z 2021 roku i obejmuje aplikacje działające między innymi na systemach Windows oraz Linux.
OWASP Desktop App Security Top 10:2021
- DA1 – Injections
- DA2 – Broken Authentication and Session Management
- DA3 – Sensitive Data Exposure
- DA4 – Improper Cryptography Usage
- DA5 – Improper Authorization
- DA6 – Security Misconfiguration
- DA7 – Insecure Communication
- DA8 – Poor Code Quality
- DA9 – Using Components with Known Vulnerabilities
- DA10 – Insufficient Logging and Monitoring
DA1 – Injections
Wstrzyknięcia
Podatności typu Injection powstają wtedy, gdy niezaufane dane trafiają do interpretera jako część zapytania, polecenia lub wykonywanego kodu.
Aplikacje desktopowe mogą być podatne między innymi na:
- SQL Injection,
- OS Command Injection,
- LDAP Injection,
- XPath Injection,
- XML Injection,
- HTML Injection,
- Template Injection.
Aplikacja może korzystać z lokalnej bazy danych, komunikować się ze zdalną bazą, przetwarzać pliki XML, wykonywać polecenia systemowe albo wysyłać dane do API. W każdym z tych miejsc brak odpowiedniej walidacji może prowadzić do wstrzyknięcia niebezpiecznej zawartości.
Przykład
Aplikacja umożliwia użytkownikowi wygenerowanie raportu na podstawie nazwy pliku. Podana wartość jest bezpośrednio doklejana do polecenia systemowego.
Atakujący zamiast zwykłej nazwy pliku przekazuje dodatkowe polecenie. Aplikacja wykonuje je z uprawnieniami procesu, w którym została uruchomiona.
Inny przykład może dotyczyć lokalnej bazy SQLite. Aplikacja tworzy zapytanie SQL poprzez łączenie tekstu wpisanego przez użytkownika, zamiast korzystać z parametrów.
Co powinien sprawdzić tester?
- pola tekstowe i formularze,
- parametry importowanych plików,
- nazwy plików oraz katalogów,
- wartości przekazywane do poleceń systemowych,
- zapytania wykonywane do lokalnej i zdalnej bazy danych,
- dane pobierane z plików XML i JSON,
- parametry przekazywane do API,
- dane zapisywane w konfiguracji,
- obsługę znaków specjalnych,
- reakcję aplikacji na długie i nietypowe wartości.
Tester powinien pamiętać, że aplikacja desktopowa może być jednocześnie klientem dla API. W takim przypadku należy testować zarówno interfejs aplikacji, jak i żądania wysyłane do backendu.
DA2 – Broken Authentication and Session Management
Błędy uwierzytelniania i zarządzania sesją
Aplikacja desktopowa może posiadać własny mechanizm logowania, korzystać z konta systemu operacyjnego, domeny, karty RFID, klucza USB, certyfikatu albo zewnętrznego dostawcy tożsamości.
Problem pojawia się, gdy mechanizmy uwierzytelniania i obsługi sesji można ominąć, zmanipulować albo wykorzystać do przejęcia tożsamości użytkownika.
Dotyczy to między innymi:
- słabych haseł,
- braku blokady konta,
- niewłaściwego przechowywania sesji,
- pozostawienia aktywnej sesji po wylogowaniu,
- braku unieważnienia tokenu,
- lokalnego zapisywania danych logowania,
- możliwości ominięcia ekranu logowania,
- błędnej obsługi uwierzytelniania urządzeń zewnętrznych.
Przykład
Użytkownik loguje się do aplikacji, a token sesji zostaje zapisany w lokalnym pliku konfiguracyjnym.
Po wylogowaniu token nadal jest aktywny. Osoba posiadająca dostęp do komputera może skopiować go i wykorzystać do wysyłania żądań do API bez znajomości hasła użytkownika.
Co powinien sprawdzić tester?
- możliwość pominięcia logowania,
- zachowanie po wielokrotnych błędnych próbach,
- obsługę wygasania sesji,
- działanie wylogowania,
- unieważnienie tokenów po zmianie hasła,
- możliwość ponownego wykorzystania starego tokenu,
- przechowywanie danych logowania na dysku,
- przechowywanie tokenów w pamięci,
- automatyczne logowanie użytkownika,
- możliwość skopiowania sesji na inny komputer,
- uwierzytelnianie podczas importu i eksportu danych,
- dostęp do funkcji po utracie połączenia z serwerem,
- dostęp do aplikacji po zablokowaniu konta.
Szczególną uwagę warto zwrócić na aplikacje działające na komputerach współdzielonych, kioskach, terminalach i stanowiskach produkcyjnych.
DA3 – Sensitive Data Exposure
Ujawnienie danych wrażliwych
Aplikacje desktopowe często przechowują dane lokalnie. Mogą to być:
- dane osobowe,
- dane finansowe,
- dokumenty,
- hasła,
- klucze API,
- tokeny,
- connection stringi,
- klucze szyfrujące,
- dane medyczne,
- dane klientów,
- informacje biznesowe.
Dane mogą zostać ujawnione przez pliki konfiguracyjne, logi, pamięć procesu, cache, pliki tymczasowe, kopie zapasowe, bibliotekę DLL albo sam plik wykonywalny.
Problemem jest również pozostawienie danych w pamięci po wylogowaniu lub zakończeniu operacji.
Przykład
Aplikacja zapisuje dane dostępowe do bazy danych w pliku konfiguracyjnym znajdującym się w katalogu programu.
Każdy użytkownik komputera może odczytać plik i uzyskać login, hasło oraz adres produkcyjnej bazy danych.
Innym przykładem jest zapisanie tokena API w logach diagnostycznych lub pozostawienie odszyfrowanego dokumentu w katalogu plików tymczasowych.
Co powinien sprawdzić tester?
- zawartość plików konfiguracyjnych,
- katalogi aplikacji,
- katalog użytkownika,
- pliki tymczasowe,
- logi aplikacji,
- pliki instalacyjne,
- biblioteki DLL,
- pliki wykonywalne,
- lokalne bazy danych,
- cache aplikacji,
- schowek systemowy,
- pliki eksportowane przez aplikację,
- dane pozostające po odinstalowaniu programu,
- dane obecne w pamięci po wylogowaniu,
- uprawnienia do plików zawierających dane wrażliwe.
Warto sprawdzić nie tylko miejsce docelowego zapisu danych, ale również wszystkie etapy ich przetwarzania.
Dokument może być ostatecznie zaszyfrowany, ale wcześniej jego jawna kopia mogła zostać pozostawiona w katalogu tymczasowym.
DA4 – Improper Cryptography Usage
Nieprawidłowe wykorzystanie kryptografii
Samo zastosowanie szyfrowania nie oznacza jeszcze, że dane są bezpieczne.
Problem może wynikać z:
- używania przestarzałych algorytmów,
- zbyt krótkich kluczy,
- własnych mechanizmów szyfrowania,
- błędnego zarządzania kluczami,
- powtarzalnych wartości inicjalizacyjnych,
- współdzielenia jednego klucza przez wszystkie instalacje,
- użycia szyfrowania zamiast haszowania,
- przechowywania klucza obok zaszyfrowanych danych,
- braku kontroli integralności.
OWASP zwraca również uwagę na używanie tych samych parametrów kryptograficznych we wszystkich instalacjach aplikacji. Przejęcie jednego klucza może wtedy zagrozić wszystkim użytkownikom produktu.
Przykład
Aplikacja szyfruje lokalną bazę danych, ale klucz szyfrujący jest zapisany bezpośrednio w pliku wykonywalnym.
Atakujący przeprowadza analizę aplikacji, odzyskuje klucz i odszyfrowuje dane wszystkich użytkowników korzystających z tego samego mechanizmu.
Co powinien sprawdzić tester?
- stosowane algorytmy kryptograficzne,
- długość kluczy,
- sposób generowania kluczy,
- sposób przechowywania kluczy,
- używanie jednego klucza w wielu instalacjach,
- przechowywanie haseł,
- wykorzystanie losowych wartości,
- sposób tworzenia wartości salt i IV,
- możliwość odszyfrowania danych po skopiowaniu ich na inny komputer,
- kontrolę integralności aktualizacji,
- podpisywanie plików,
- reakcję na zmodyfikowane dane,
- możliwość cofnięcia aplikacji do słabszego mechanizmu kryptograficznego.
Warto wyraźnie rozdzielić DA3 i DA4.
DA3 dotyczy ujawnienia informacji wrażliwych. DA4 dotyczy błędnego zastosowania mechanizmów kryptograficznych, które miały te informacje chronić.
DA5 – Improper Authorization
Nieprawidłowa autoryzacja
Autoryzacja określa, jakie operacje może wykonać dany użytkownik lub proces.
W przypadku aplikacji desktopowej nie chodzi wyłącznie o role wewnątrz programu. Znaczenie mają również:
- uprawnienia do plików,
- dostęp do katalogów,
- uprawnienia do rejestru,
- zmienne środowiskowe,
- uprawnienia usług,
- możliwość zmiany konfiguracji,
- możliwość podmiany pliku wykonywalnego,
- dostęp do funkcji administracyjnych.
Aplikacja lub jej usługa nie powinna działać z większymi uprawnieniami, niż jest to rzeczywiście potrzebne.
Przykład
Aplikacja uruchamia usługę działającą jako administrator systemu. Plik konfiguracyjny tej usługi może jednak zmienić zwykły użytkownik.
Atakujący modyfikuje konfigurację i wskazuje własny plik wykonywalny. Po ponownym uruchomieniu usługi jego kod zostaje wykonany z uprawnieniami administratora.
Co powinien sprawdzić tester?
- działanie aplikacji na koncie zwykłego użytkownika,
- funkcje dostępne bez uprawnień administratora,
- możliwość zmiany plików konfiguracyjnych,
- możliwość modyfikowania plików wykonywalnych i bibliotek,
- uprawnienia do katalogu instalacyjnego,
- dostęp do wpisów w rejestrze,
- możliwość zmiany ról użytkownika,
- dostęp do funkcji administracyjnych,
- możliwość manipulowania identyfikatorem użytkownika,
- uprawnienia usług działających w tle,
- możliwość uruchomienia programu z innym profilem,
- kontrolę dostępu po stronie API.
Ukrycie przycisku w interfejsie nie jest mechanizmem autoryzacji.
Nawet jeśli zwykły użytkownik nie widzi funkcji administracyjnej, nadal może spróbować wywołać ją bezpośrednio, zmienić konfigurację albo wysłać odpowiednie żądanie do backendu.
DA6 – Security Misconfiguration
Błędna konfiguracja bezpieczeństwa
Aplikacja może być poprawnie napisana, ale działać w niebezpiecznie skonfigurowanym środowisku.
Podatności mogą wynikać między innymi z:
- błędnych reguł zapory,
- nieprawidłowych wpisów w rejestrze,
- słabych zasad grupowych,
- niezabezpieczonych named pipes,
- niebezpiecznej konfiguracji usług,
- domyślnych haseł,
- otwartych portów,
- braku sprawdzania typu pliku,
- nadmiernych uprawnień katalogów,
- wystawienia lokalnego interfejsu do sieci,
- błędnej konfiguracji baz danych i usług zewnętrznych.
Przykład
Aplikacja uruchamia lokalny serwer HTTP, który powinien być dostępny wyłącznie z komputera użytkownika.
Z powodu błędnej konfiguracji usługa nasłuchuje na wszystkich interfejsach sieciowych. Inne urządzenia w sieci mogą połączyć się z panelem i wywoływać funkcje aplikacji.
Co powinien sprawdzić tester?
- porty otwierane po instalacji,
- procesy i usługi uruchamiane w tle,
- reguły zapory,
- konfigurację named pipes,
- uprawnienia do rejestru,
- domyślne dane logowania,
- konfigurację lokalnej bazy danych,
- interfejsy administracyjne,
- działanie trybu debugowania,
- komunikaty błędów,
- możliwość przesyłania nieobsługiwanych typów plików,
- ustawienia parserów dokumentów,
- konfigurację środowiska testowego i produkcyjnego,
- niepotrzebne funkcje w instalacji produkcyjnej.
Testy warto wykonać zarówno na świeżej instalacji, jak i po aktualizacji wcześniejszej wersji programu.
Niebezpieczne ustawienia mogą pozostać po starej instalacji, nawet jeśli nowa wersja aplikacji posiada już poprawną konfigurację domyślną.
DA7 – Insecure Communication
Niezabezpieczona komunikacja
Aplikacja desktopowa może komunikować się z:
- API,
- bazą danych,
- serwerem plików,
- usługą aktualizacji,
- systemem licencyjnym,
- usługą chmurową,
- brokerem wiadomości,
- inną aplikacją lub urządzeniem.
Jeżeli komunikacja odbywa się bez odpowiedniego szyfrowania albo aplikacja nie weryfikuje certyfikatu, atakujący może podsłuchiwać i modyfikować przesyłane dane.
Problem obejmuje używanie protokołów przesyłających dane jawnym tekstem, słabych wersji TLS i niewłaściwej walidacji certyfikatów.
Przykład
Aplikacja wysyła dane logowania do serwera przez HTTP.
Osoba znajdująca się w tej samej sieci przechwytuje ruch i uzyskuje login, hasło oraz token sesji użytkownika.
Inny przykład to aplikacja akceptująca dowolny certyfikat TLS. Atakujący może wtedy przeprowadzić atak Man-in-the-Middle.
Co powinien sprawdzić tester?
- protokoły używane przez aplikację,
- szyfrowanie ruchu,
- wersje TLS,
- obsługiwane zestawy szyfrów,
- walidację certyfikatu,
- reakcję na certyfikat wygasły,
- reakcję na certyfikat wystawiony dla innej domeny,
- reakcję na certyfikat samopodpisany,
- możliwość przeprowadzenia ataku Man-in-the-Middle,
- transmisję danych logowania,
- połączenia z bazą danych,
- ruch generowany przez mechanizm aktualizacji,
- możliwość zmiany adresu serwera,
- wysyłanie danych diagnostycznych i telemetrycznych.
Nie należy ograniczać analizy wyłącznie do ruchu HTTP. Aplikacja może korzystać także z własnych protokołów, WebSocketów, MQTT, połączeń bazodanowych lub komunikacji pomiędzy procesami.
DA8 – Poor Code Quality
Niska jakość kodu
Niska jakość kodu w aplikacji desktopowej może prowadzić nie tylko do błędów funkcjonalnych, ale również do poważnych podatności bezpieczeństwa.
OWASP wskazuje między innymi na:
- brak podpisywania kodu,
- brak weryfikacji integralności plików,
- błędy zarządzania pamięcią,
- przepełnienia bufora,
- wycieki pamięci,
- DLL preloading,
- DLL injection,
- race conditions,
- brak ochrony plików binarnych,
- pozostawienie kodu testowego,
- możliwość łatwego modyfikowania programu.
Przykład
Aplikacja ładuje bibliotekę DLL, wyszukując ją najpierw w katalogu roboczym użytkownika.
Atakujący umieszcza w tym katalogu własną bibliotekę o odpowiedniej nazwie. Po uruchomieniu aplikacji złośliwy kod zostaje załadowany razem z programem.
Co powinien sprawdzić tester?
- podpis cyfrowy aplikacji,
- reakcję na zmodyfikowany plik wykonywalny,
- sposób ładowania bibliotek,
- katalogi przeszukiwane podczas ładowania DLL,
- odporność na bardzo duże dane wejściowe,
- obsługę uszkodzonych plików,
- reakcję na niepełne dane,
- zarządzanie pamięcią,
- pozostawione funkcje testowe,
- komunikaty debugowania,
- możliwość podmiany bibliotek,
- mechanizmy integralności,
- zachowanie aplikacji podczas jednoczesnych operacji,
- błędy występujące przy szybkim powtarzaniu tej samej czynności.
Obfuskacja może utrudnić analizę kodu, ale nie naprawia podatności. Nie powinna być traktowana jako główny mechanizm bezpieczeństwa.
DA9 – Using Components with Known Vulnerabilities
Używanie komponentów ze znanymi podatnościami
Aplikacja desktopowa rzadko jest tworzona całkowicie od podstaw.
Może wykorzystywać:
- biblioteki open source,
- komponenty komercyjne,
- frameworki,
- sterowniki,
- usługi systemowe,
- runtime,
- wbudowane przeglądarki,
- parsery dokumentów,
- biblioteki kryptograficzne,
- komponenty do obsługi multimediów.
Jeżeli jeden z tych elementów posiada znaną podatność, atakujący może wykorzystać ją do przejęcia aplikacji lub całego systemu.
Dotyczy to również zależności pośrednich. Aplikacja może korzystać z biblioteki, która sama wykorzystuje kolejną podatną bibliotekę.
Przykład
Aplikacja wykorzystuje starą bibliotekę do przetwarzania plików graficznych.
Atakujący przygotowuje specjalnie zmodyfikowany plik. Po jego otwarciu dochodzi do wykonania kodu na komputerze użytkownika.
Co powinien sprawdzić tester?
- wersje bibliotek,
- wersje frameworków,
- wersję używanego runtime,
- komponenty dołączone do instalatora,
- biblioteki ładowane podczas działania,
- znane podatności CVE,
- zależności pośrednie,
- proces aktualizowania komponentów,
- możliwość zaktualizowania aplikacji,
- komponenty niewspierane przez producenta,
- obecność SBOM,
- czas pomiędzy publikacją poprawki a jej wdrożeniem,
- komponenty systemowe wymagane przez program.
Lista komponentów powinna być aktualna i dostępna przez cały cykl życia produktu.
Bez wiedzy o tym, jakie biblioteki znajdują się w aplikacji, trudno szybko odpowiedzieć na informację o nowej podatności.
DA10 – Insufficient Logging and Monitoring
Niewystarczające logowanie i monitorowanie
Logi są potrzebne do diagnozowania problemów, audytowania operacji oraz wykrywania ataków.
Samo tworzenie plików z logami nie oznacza jednak, że mechanizm został poprawnie wdrożony.
Problem może polegać na:
- braku logowania ważnych operacji,
- braku informacji o użytkowniku,
- braku poprawnego znacznika czasu,
- możliwości modyfikowania logów,
- zapisywaniu logów w publicznym katalogu,
- braku centralnego monitoringu,
- braku alertów,
- zapisywaniu haseł i tokenów,
- możliwości wstrzyknięcia fałszywego wpisu,
- braku powiązania zdarzeń z konkretną sesją.
OWASP rozróżnia między innymi logi aplikacyjne, debugowe oraz audytowe. Mechanizm monitorowania powinien następnie wykorzystywać te informacje do wykrywania nietypowych i niebezpiecznych zachowań.
Przykład
Aplikacja umożliwia eksport poufnych danych, ale nie zapisuje informacji o tym, kto wykonał eksport, kiedy został wykonany i jakie rekordy zostały pobrane.
Po incydencie organizacja nie jest w stanie ustalić, który użytkownik skopiował dane.
Inny problem występuje, gdy aplikacja zapisuje pełny token sesji w logach dostępnych dla zwykłych użytkowników.
Co powinien sprawdzić tester?
- logowanie udanych i nieudanych prób logowania,
- logowanie zmian uprawnień,
- logowanie operacji administracyjnych,
- logowanie eksportu danych,
- logowanie zmian konfiguracji,
- rejestrowanie użytkownika wykonującego operację,
- obecność poprawnego czasu zdarzenia,
- możliwość modyfikowania logów,
- uprawnienia do katalogów z logami,
- obecność sekretów i danych osobowych,
- odporność na Log Injection,
- działanie alertów,
- rotację oraz retencję logów,
- zachowanie po zapełnieniu dysku,
- powiązanie logów aplikacji z logami systemowymi.
Logowanie powinno zapewniać rozliczalność, ale nie może samo prowadzić do ujawnienia informacji wrażliwych.
Jak tester powinien podejść do aplikacji desktopowej?
Testowanie aplikacji desktopowej nie powinno ograniczać się do jej interfejsu użytkownika.
Należy przeanalizować cały ekosystem:
- Instalator aplikacji.
- Proces instalacji i aktualizacji.
- Pliki oraz katalogi tworzone przez program.
- Uprawnienia systemowe.
- Procesy i usługi działające w tle.
- Wpisy w rejestrze i zmienne środowiskowe.
- Komunikację sieciową.
- Lokalne oraz zdalne bazy danych.
- Mechanizmy uwierzytelniania i autoryzacji.
- Pliki wykonywalne i biblioteki.
- Obsługę importowanych dokumentów.
- Logi, monitoring oraz telemetrię.
- Zachowanie po odinstalowaniu programu.
W praktyce aplikacja desktopowa może łączyć ryzyka charakterystyczne dla kilku obszarów:
- aplikacji webowych,
- API,
- systemu operacyjnego,
- lokalnych baz danych,
- aplikacji mobilnych,
- usług sieciowych,
- infrastruktury firmowej.
Przykładowy zakres testów bezpieczeństwa
Instalacja
Tester powinien sprawdzić:
- czy instalator posiada podpis cyfrowy,
- czy wymaga uprawnień administratora,
- jakie pliki tworzy,
- jakie usługi instaluje,
- jakie porty otwiera,
- jakie reguły zapory dodaje,
- jakie zmiany wprowadza w rejestrze,
- czy instaluje dodatkowe komponenty,
- czy pozostawia pliki tymczasowe.
Uruchomienie aplikacji
Warto zweryfikować:
- z jakimi uprawnieniami działa proces,
- jakie procesy potomne uruchamia,
- jakie biblioteki ładuje,
- z jakimi adresami sieciowymi się łączy,
- jakie pliki otwiera,
- gdzie zapisuje dane,
- czy uruchamia lokalne usługi.
Przetwarzanie danych
Należy przetestować:
- błędne formaty plików,
- bardzo duże pliki,
- uszkodzone dokumenty,
- nieobsługiwane rozszerzenia,
- nazwy zawierające znaki specjalne,
- ścieżki względne,
- próby Path Traversal,
- pliki zawierające złośliwe dane,
- jednoczesne przetwarzanie wielu plików.
Komunikacja
Tester powinien przeanalizować:
- szyfrowanie ruchu,
- walidację certyfikatów,
- wysyłane nagłówki,
- wykorzystywane tokeny,
- możliwość zmiany żądania,
- kontrolę dostępu po stronie serwera,
- zachowanie bez połączenia z Internetem,
- obsługę błędów i timeoutów,
- ponawianie operacji.
Aktualizacja
Mechanizm aktualizacji powinien zostać sprawdzony pod kątem:
- źródła pobierania aktualizacji,
- szyfrowania transmisji,
- podpisu cyfrowego,
- weryfikacji integralności,
- możliwości podmiany pliku,
- możliwości instalacji starszej wersji,
- uprawnień procesu aktualizującego,
- zachowania po przerwaniu aktualizacji.
OWASP Desktop Top 10 a OWASP Web Top 10
Obie listy częściowo się pokrywają, ale patrzą na aplikację z innej perspektywy.
W obu przypadkach występują między innymi:
- Injection,
- błędy uwierzytelniania,
- błędy autoryzacji,
- problemy z kryptografią,
- błędna konfiguracja,
- podatne komponenty,
- niewystarczające logowanie.
W przypadku aplikacji desktopowej większe znaczenie mają jednak również:
- lokalny system plików,
- pamięć procesu,
- rejestr systemowy,
- usługi działające w tle,
- uprawnienia systemu operacyjnego,
- pliki wykonywalne,
- biblioteki DLL,
- podpisywanie kodu,
- reverse engineering,
- bezpieczeństwo instalatora,
- fizyczny dostęp do komputera.
Aplikacji desktopowej nie należy więc traktować wyłącznie jako interfejsu do API. Sam klient również może zawierać istotne podatności.
Podsumowanie
OWASP Desktop App Security Top 10 pokazuje, że testowanie aplikacji desktopowych wymaga szerszego podejścia niż standardowe sprawdzenie funkcji dostępnych w interfejsie.
Tester powinien analizować nie tylko to, co użytkownik widzi na ekranie, ale również:
- sposób instalacji aplikacji,
- jej uprawnienia,
- komunikację sieciową,
- lokalnie zapisane dane,
- wykorzystywane biblioteki,
- mechanizmy aktualizacji,
- konfigurację systemową,
- logi,
- pliki wykonywalne,
- zachowanie usług działających w tle.
Szczególnie niebezpieczne są sytuacje, w których aplikacja desktopowa działa z wysokimi uprawnieniami, przetwarza dane wrażliwe i jednocześnie komunikuje się z wieloma systemami zewnętrznymi.
OWASP Desktop App Security Top 10 nie jest kompletną metodyką testów bezpieczeństwa. Stanowi jednak bardzo dobry punkt wyjścia do przygotowania:
- checklisty testowej,
- scenariuszy bezpieczeństwa,
- zakresu audytu,
- analizy ryzyka,
- wymagań dla zespołu developerskiego,
- kryteriów akceptacji aplikacji desktopowej.
Najważniejsze jest holistyczne spojrzenie na produkt. Bezpieczny interfejs nie wystarczy, jeżeli token znajduje się w pliku konfiguracyjnym, aplikacja akceptuje każdy certyfikat, a zwykły użytkownik może podmienić bibliotekę uruchamianą przez usługę administratora.
