Testy penetracyjne aplikacji webowych

Celem testów penetracyjnych jest m.in. praktyczna ocena ogólnego poziomu bezpieczeństwa gwarantowanego przez przedmiot badań, wykrycie obecności podatności oraz zweryfikowanie odporności na próby sforsowania zabezpieczeń.
W ramach testów penetracyjnych zidentyfikujemy podatności w objętej badaniem systemie oraz zaproponujemy szczegółowe działania naprawcze mające na celu ograniczenie zidentyfikowanych ryzyk. Do każdego testu podchodzimy indywidualnie, co pozwala na przeprowadzenie analizy uwzględniającej potencjalne wektory ataków.

1

Bezpłatne konsultacje

Chętnie odpowiemy na Twoje pytania lub wątpliwości 

SZCZEGÓŁOWE CELE TESTÓW:

  • niezależne określenie stanu bezpieczeństwa aplikacji webowej,
  • wykrycie podatności aplikacji,
  • wskazanie rekomendacji zwiększających bezpieczeństwo.

KORZYŚCI:

  • spełnienie wymagań prawnych i organizacyjnych (RODO, NIS, REKOMENDACJE KNF),
  • weryfikacja odporności infrastruktury na najczęściej występujące wektory ataków
  • wykrycie potencjalnych słabych punktów i podatności oraz wskazanie działań naprawczych
  • weryfikacja skuteczności istniejących mechanizmów prewencyjnych
  • umożliwia zademonstrowanie administratorom sieci, menadżerom IT i zarządowi jakie mogą być konsekwencje prawdziwego włamania do aplikacji,
  • raport z testów pomaga wdrożyć nowe lub poprawić dotychczasowe rozwiązania bezpieczeństwa.

 PRZYKŁADOWY ZAKRES TESTÓW:

Rekonesans aktywny i pasywny (w przypadku aplikacji dostępnych w Internecie):

  • Próby lokalizacji aplikacji dostępnej pod innym adresem (np. aplikacja deweloperska w infrastrukturze dostawcy, publicznie dostępna aplikacja w wersji testowej)
  • Próby lokalizacji ukrytych katalogów i plików
  • Próby wywołania błędów / wyjątków w aplikacji
  • Poszukiwanie innych domen dostępnych na tym samym adresie IP co domena bazowa
  • Poszukiwanie wycieków danych (np. technika Google Hacking, analiza pliku robots.txt).

Poszukiwanie podatności:

  • Podatności klasy injection (np. SQL injection,)
  • Podatność XXE (użycie zewnętrznych encji XML)
  • Podatność XSS (Cross Site Scripting)
  • Analiza problemów z uwierzytelnianiem i autoryzacją (np. próby dostępu do zasobów bez uwierzytelnienia, próby dostępu do zasobów administracyjnych przez zwykłego użytkownika, próby przełamania ekranów logowania – w tym próby brute force danych dostępowych).
  • Możliwości otrzymania nieautoryzowanego dostępu na poziomie systemu operacyjnego i uzyskanie w ten sposób dostępu do źródeł aplikacji, bazy danych, innych poufnych informacji.
  • Próby realizacji aplikacyjnych ataków typu DoS (po wcześniejszym uzgodnieniu)
  • Analiza błędów logicznych
  • Próby wykrycia innych, znanych podatności, np.: Path Traversal, Open Redirection, Cross Site Request Forgery, Server Side Request Forgery, Server Side Template Injection.
  • Detekcja ogólnie znanego oprogramowania (aplikacje, biblioteki, systemy wspomagające).
  • Po wykryciu nieaktualnych wersji, próby lokalizacji znanych, istotnych podatności w kilku wybranych źródłach

 PRZYKŁAD ZAKRES TESTÓW DLA CMS – WORDPRESS

  • Ustalenie wykorzystywanej wersji systemu WordPress.
  • Enumeracja wersji wykorzystywanych szablonów (themes) oraz wtyczek (plugins) -próby wykrycia nieaktualnych komponentów.
  • Enumeracja wykorzystania nadmiarowych (niewykorzystywanych) szablonów i wtyczek.
  • Weryfikacja ujawniania nadmiarowych informacji o systemie WordPress (pliki readme, możliwość enumeracji użytkowników systemu, etc).
  • Weryfikacja zabezpieczenia dostępu do panelu administracyjnego WordPress.
  • Weryfikacja obecności dodatkowych technik hardeningowych metodami blackbox (np. modyfikacja domyślnych ścieżek do plików szablonów oraz wtyczek).

METODA TESTÓW

  • Wariant blackbox – badania realizowane są z perspektywy potencjalnego agresora, w związku z tym pentesterowi nie są przekazywane żadne dodatkowe informacje nt. przedmiotu badań poza dostępnymi publicznie w sieci Internet (np. adres URL aplikacji internetowej, która podlega badaniom). W takim wariancie audytor musi sam rozpoznać środowisko działania badanego obiektu, pozyskać niezbędne informacje m.in. nt. jego konfiguracji, podjąć próby założenia konta (np. klienta w aplikacji internetowej), aby na tej podstawie przygotować scenariusze potencjalnie skutecznych nadużyć.
  • Testy w wariancie graybox obejmują weryfikację obiektu badań zarówno z poziomu użytkownika niezalogowanego, jak i zalogowanego (najczęściej na konta o różnym poziomie uprawnień). W przypadku tych testów weryfikowana jest przede wszystkim poprawność działania mechanizmów odpowiedzialnych za przydzielanie i ograniczanie dostępu do poszczególnych części składowych aplikacji w zależności od nadanych uprawnień. Dodatkowo audytorzy podejmują próby eskalacji uprawnień, które zrealizowane w sposób skuteczny pozwolą uzyskać szerszy dostęp do przedmiotu badań, np. dostęp do funkcji administracyjnych z poziomu konta „zwykłego” użytkownika. Testy graybox często odpowiadają scenariuszowi, w którym agresor uzyskał dostęp do komputera pracownika i realizuje próby nadużyć, bądź agresorem jest sam pracownik.
  • Wariant whitebox, który cechuje się realizacją testów penetracyjnych z wykorzystaniem niemal pełnej wiedzy o badanym obiekcie. W przypadku tych testów audytorzy posiadają dodatkowo (względem wariantu graybox) m.in. dostęp do dokumentacji rozwiązania, niezaciemnionego kodu źródłowego, konfiguracji urządzeń sieciowych obsługujących środowisko pracy systemu itp

METODYKA:

  • OWASP (Open Web Application Security Project);
  • OWASP ASVS (Application Security Verification Standard Project)
  • PN-ISO/IEC serii 27000.

NARZĘDZIA:

 Do realizacji testów wykorzystujemy sprawdzone narzędzia zarówno komercyjne jak również tworzone przez naszych inżynierów bezpieczeństwa. Nasze narzędzia są projektowane i tworzone pod konkretne systemy i zagrożenia, tak aby zapewnić ich najwyższą skuteczność w realizacji testów.

  • Burp Suite
  • Nmap
  • Nikto2
  • Scapy
  • Nessus
  • W3af
  • OpenVAS
  • Dirbuster
  • SQLmap
  • Metasploit
  • Własne skrypty i narzędzia

WYNIKI:

  • Raport dla zarządu:
    • Podsumowanie wykonanych prac.
    • Skrótowy opis najistotniejszych znalezionych podatności (tj. błędów bezpieczeństwa).
    • Szacowany poziom bezpieczeństwa aplikacji (odporności na ataki).
  • Szczegółowy raport techniczny:
    • Cel i zakres.
    • Metodyka oraz narzędzia.
    • Zidentyfikowane podatności i rekomendacje ich naprawy.
    • Dowody potwierdzające zidentyfikowane podatności.
    • Klasyfikacja podatności – Tabela ryzyk.

Proszę o informację o ofercie

Dziękujemy!