Bezpieczeństwo aplikacji internetowych
Testy penetracyjne aplikacji webowych i API
Testy penetracyjne aplikacji webowych zaczynamy od kontroli dostępu. Najdroższe podatności rzadko wynikają z braku łatki — zwykle z tego, że jeden użytkownik może sięgnąć po dane innego.
Typowy projekt trwa od 2 do 4 tygodni. Retesty poprawek są bezpłatne i nielimitowane.
Punkt wyjścia
Dlaczego skaner nie wystarcza w aplikacji biznesowej
Skaner potrafi rozpoznać wzorzec, który już zna: nieaktualną bibliotekę, brakujący nagłówek, klasyczne wstrzyknięcie kodu. Nie wie natomiast, że w Państwa aplikacji użytkownik roli „księgowość” nie powinien widzieć umów innego oddziału ani że zmiana identyfikatora w treści żądania pozwala zatwierdzić własny wniosek urlopowy dwa razy.
Te błędy nie mają sygnatury, ponieważ wynikają z reguł biznesowych obowiązujących wyłącznie w Państwa organizacji. Wykrywa je człowiek, który rozumie proces i celowo próbuje go obejść. Dlatego w każdym projekcie prosimy o konta testowe dla wszystkich ról i weryfikujemy uprawnienia rola po roli oraz pomiędzy kontami różnych klientów tej samej platformy.
Efektem jest raport, w którym obok podatności technicznych znajdą Państwo scenariusze nadużycia opisane językiem procesu — takie, które da się przekazać zarówno zespołowi deweloperskiemu, jak i właścicielowi biznesowemu aplikacji.
Obszary testów
Co sprawdzamy w aplikacji webowej
Zakres obejmuje warstwę aplikacyjną, interfejsy programistyczne oraz elementy infrastruktury, które bezpośrednio wpływają na bezpieczeństwo aplikacji.
Uwierzytelnianie i zarządzanie sesją
Odporność logowania na ataki automatyczne, poprawność wdrożenia uwierzytelniania wieloskładnikowego, procedura odzyskiwania hasła, czas życia i unieważnianie sesji oraz obsługa tokenów odświeżających.
Kontrola dostępu i autoryzacja
Testujemy dostęp poziomy i pionowy: czy użytkownik sięgnie po dane innego konta oraz czy uzyska funkcje zarezerwowane dla administratora. W aplikacjach wielodostępnych sprawdzamy izolację danych między klientami.
Logika biznesowa
Obejścia kolejności kroków w procesie, manipulacja ceną i rabatem, powielanie transakcji, wyścigi przy równoległych żądaniach oraz nadużycia limitów przyznanych kontu.
Wstrzyknięcia i obsługa danych wejściowych
SQL injection, wstrzyknięcia NoSQL i poleceń systemowych, XSS w wariancie odbitym, trwałym i opartym o DOM, SSTI oraz niebezpieczna deserializacja danych.
Bezpieczeństwo API
REST, GraphQL i SOAP. Autoryzacja na poziomie obiektu i funkcji, nadmiarowe zwracanie danych, brak limitów zapytań, nieudokumentowane punkty końcowe oraz stare, wciąż aktywne wersje interfejsu.
Przesyłanie plików i integracje
Walidacja typu i zawartości plików, ścieżki zapisu, żądania po stronie serwera (SSRF), bezpieczeństwo webhooków oraz sposób przechowywania kluczy do usług zewnętrznych.
Przebieg
Jak prowadzimy test aplikacji webowej
Projekt trwa zwykle od dwóch do czterech tygodni, zależnie od liczby ról, punktów końcowych i złożoności procesów.
- 01
Warsztat wprowadzający
Poznajemy przeznaczenie aplikacji, role użytkowników, najbardziej wrażliwe operacje oraz obszary, które budzą największe obawy Państwa zespołu.
- 02
Mapowanie powierzchni ataku
Przechodzimy przez całą aplikację jako każda z ról, katalogujemy funkcje, punkty końcowe API i miejsca, w których dane przekraczają granicę zaufania.
- 03
Testy techniczne
Weryfikujemy warstwę wejściową, uwierzytelnianie i konfigurację — ta część korzysta z narzędzi, ale każdy wynik potwierdzamy ręcznie, aby wykluczyć fałszywe alarmy.
- 04
Testy autoryzacji i logiki
Najbardziej pracochłonny etap: próbujemy wykonać operacje spoza uprawnień roli i obejść reguły procesu biznesowego. Stąd pochodzi większość znalezisk krytycznych.
- 05
Raport i omówienie
Przekazujemy raport oraz prowadzimy sesję dla deweloperów, na której pokazujemy odtworzenie najważniejszych podatności na żywo i odpowiadamy na pytania.
- 06
Retesty poprawek
Po wdrożeniu zmian weryfikujemy każde znalezisko ponownie, bezpłatnie i bez limitu prób, a wynik dopisujemy do raportu wraz z datą.
Zgodność
Aplikacja webowa a polskie wymagania
Te cztery obszary pojawiają się w praktycznie każdym postępowaniu zakupowym i audycie dotyczącym aplikacji dostępnej z internetu.
RODO i nadzór UODO
Aplikacja webowa jest zwykle głównym miejscem przetwarzania danych osobowych. Artykuł 32 RODO wymaga regularnego testowania skuteczności zabezpieczeń, a artykuł 25 — uwzględnienia ochrony danych już na etapie projektowania. Raport dokumentuje jedno i drugie, wraz z datami i wynikiem retestów.
PCI DSS dla e-commerce
Sklepy i platformy przyjmujące płatności kartą podlegają wymaganiu 6.4.1 dotyczącemu ochrony aplikacji publicznych oraz 11.4 dotyczącemu testów penetracyjnych. Sprawdzamy również, czy skrypty na stronie płatności nie umożliwiają przechwycenia danych karty.
KRI w sektorze publicznym
Rozporządzenie w sprawie Krajowych Ram Interoperacyjności wymaga od podmiotów publicznych okresowego audytu bezpieczeństwa informacji, nie rzadziej niż raz w roku. Testy portalu lub systemu dziedzinowego są najczęściej wybieraną formą wykazania tego obowiązku.
OWASP ASVS i ISO 27001
Testy prowadzimy według OWASP ASVS, dzięki czemu pokrycie jest mierzalne, a nie deklaratywne. Wyniki mapujemy na zabezpieczenia A.8.8 i A.8.29 z Załącznika A do ISO 27001, co pozwala wpiąć raport bezpośrednio w dokumentację systemu zarządzania.
Najczęstsze pytania
Testy aplikacji webowych — pytania klientów
Powiązane usługi
Sprawdźmy, czy użytkownik sięgnie po cudze dane
Prosimy o kontakt, aby ustalić zakres testu aplikacji webowej i otrzymać wycenę. Konsultacja wstępna jest bezpłatna.
Prosimy o kontakt