Sekcje

Przejdź na skróty do treści. | Przejdź do nawigacji


Baza wiedzy Publikacje Audyt bezpieczeństwa aplikacji WWW

Audyt bezpieczeństwa aplikacji WWW

Wstęp

audyt bezpieczeństwa aplikacji www W publikowanym w bazie wiedzy dwuczęściowym opracowaniu, przybliżymy Czytelnikowi tematykę audytu bezpieczeństwa aplikacji webowych.


W artykule odpowiemy na takie pytania jak:

  • Jakimi czynnikami zagrożone są aplikacje webowe?
  • Czym charakteryzują się testy penetracyjne?
  • Jakie elementy  dostarczane są w wyniku audytu bezpieczeństwa?
  • Kiedy decyzja o wykonaniu audytu bezpieczeństwa jest słuszna, a kiedy nie?
  • Jakie są zalety i wady audytu aplikacji?

Aplikacje webowe

Chciałbyś przećwiczyć audyt bezpieczeństwa aplikacji w praktyce? zapraszamy na szkolenie: bezpieczeństwo aplikacji www.

Aplikacje webowe zyskują coraz większą popularność. Stanowi o tym kilka czynników takich jak: rozpoznawalny i powtarzalny interface użytkownika, wykorzystanie hipertekstu, szybkość tworzenia nowych funkcjonalności, przenośność aplikacji pomiędzy platformami, centralne zarządzanie aplikacją czy możliwość użytkowania systemu z każdego miejsca w Sieci.

Obecnie popularny stał się termin web 2.0. Jednak o sile aplikacji WWW stanowi - chciałoby się powiedzieć - web 1.0. To znaczy klasyczne rozwiązania, które były rozwijane przez ostatnie 15 lat w ramach ekspansji globalnej sieci World Wide Web.

Znakomita większość aplikacji WWW działa w Internecie lub w sieci lokalnej. Jest to jedna z głównych cech, a zarazem zalet aplikacji webowych. Z tego typu ściśle sieciową architekturą wiążą się jednak pewne zagrożenia, które przedstawiamy w dalszej części tekstu.

Audyt bezpieczeństwa - architektura www

Rysunek 1. Ogólna architektura sieciowa aplikacji www - miejsca narażone na atak.

Zagrożenia dla aplikacji webowych

Często kiedy wspomina się o bezpieczeństwie aplikacji, mówi się jedynie o bezpośrednich atakach na dany system. Padają takie słowa jak: przejęcie, hacker, kompromitacja systemu, exploit. Tego typu bezpośrednie zagrożenia rzeczywiście są istotne, jednak należy również pamiętać o innych problemach mogących naruszyć bezpieczeństwo aplikacji. Przykładowo są to:

  • Zagrożenia płynące z nieuniknionych awarii sprzętu czy oprogramowania (np. awaria serwerów, czy „słynny” problem roku 2000).
  • Bezpośrednie błędy ludzkie (np. pomyłki administratorów systemów).
  • Błędy proceduralne (np. brak  wdrożonej procedury dostępu do kopii zapasowych danych przetwarzanych w aplikacji).
  • Zagrożenia naturalne (np. zalanie serwerowni).

Audyt bezpieczeństwa może przybrać formę ogólną, badającą rozmaite rodzaje zagrożeń oraz skorelowane z nimi podatności (błędy bezpieczeństwa). Może też przyjąć formę bardziej szczegółową – skupiającą się na określonej klasie zagrożeń. W celu wprowadzenia czytelnika w praktyczną tematykę audytu, skupimy się właśnie na szczegółowym typie audytu. Precyzyjniej - omówimy audyt bezpieczeństwa związany z atakiem hackerskim na aplikację.

Atak na aplikację webową - czym może skutkować?

Dla wielu osób atak na system IT wiąże się przede wszystkim z atakiem na sieć. Ochronę przed tego typu działaniami zapewniają firewalle, odpowiednio zabezpieczone systemy operacyjne, systemy IDS, czy też inne, znane od dłuższego czasu metody. Co ciekawe, obecnie większość ataków na systemy webowe udostępnione w Internecie, odbywa się na poziomie aplikacyjnym – nie sieciowym.  Dlaczego tak się dzieje? Ponieważ aplikacje, w porównaniu ze środowiskami sieciowymi są niezmiernie słabo zabezpieczone.  Jaką drogę wybierze zatem hacker atakując system IT? Najprostszą prowadzącą do celu - najczęściej jest to droga wiodąca przez aplikacje.

Jak wspomnieliśmy wcześniej, jedną z zalet oprogramowania webowego jest możliwość szybkiej realizacji rozbudowy systemu o nowe funkcjonalności . Niestety niejako „w parze” idzie za tym wysoka szybkość przełamywania tychże aplikacji. Sprawny hacker jest w stanie złamać zabezpieczenia aplikacji (a raczej wykorzystać brak zabezpieczeń) w ciągu kilkudziesięciu minut. 

Przykład 1.

Cel: zdalne osiągnięcie uprawnień administracyjnych w panelu zarządzania treścią portalu internetowego, umieszczenie w nim kompromitujących treści; dostęp do poufnych danych.

Sposób osiągnięcia celu: hacker w pierwszym kroku próbuje zlokalizować podatność klasy SQL injection. Po zlokalizowaniu błędu, przygotowanie kodu umożliwiającego odczyt lub zapis do bazy danych zajmuje raptem kilkanaście minut. Następnie hacker łamie hasła, które uzyskał z tabeli użytkowników korzystając z SQL injection. Aby użyć pozyskane hasło administratora musi jeszcze zlokalizować sam panel administracyjny. Stosuje do tego technikę google hacking. Po lokalizacji panelu, loguje się z wykorzystaniem wcześniej zdobytych danych. Posiadając uprawnienia administracyjne uzyskuje dostęp do poufnych danych klientów oraz może dowolnie modyfikować zawartość systemu. Całość ataku wykonywana jest poprzez sieć anonimizacyjną, co w zasadzie uniemożliwia lokalizację sprawcy…  Całość ataku trwa około godziny.

Przykład 2.

Cel: przejęcie dostępu do konta w sklepie internetowym oraz wykonanie zakupów na koszt innych użytkowników sklepu.

Sposób osiągnięcia celu: hacker w pierwszym kroku, na stronie sklepu internetowego umieszcza komentarz na forum dyskusyjnym. Nieświadomi użytkownicy nie wiedzą, iż komentarz zawiera złośliwy kod HTML, który wykorzystuje podatność klasy stored XSS. Jeśli zalogowany użytkownik przeczyta listę wątków forum– dane jego zalogowanej sesji zostają „w tle” przekazane do atakującego (tak został zbudowany wstrzyknięty wcześniej do sklepu szkodliwy kod HTML). Hacker loguje się na konto ofiary – dzięki pobranym danym zalogowanej sesji może to wykonać bez znajomości hasła dostępowego i loginu (!). Atakujący następnie wykonuje zakup na koszt właściciela przejętego konta. Dane karty kredytowej ofiary przechowywane są w sklepie internetowym - będąc zalogowanym jako właściciel karty nie ma potrzeby ich ponownego uzupełniania.

Czas przygotowania ataku: 2 godziny.

Dlaczego w powyższych przykładach dobraliśmy błędy SQL injection oraz XSS? Ponieważ są to obecnie jednej z najczęstszych, a zarazem wysoce niebezpiecznych podatności występujących w aplikacjach webowych.  Jak zabezpieczyć się przed tego typu atakami? Jedną z metod jest wykonanie audytu bezpieczeństwa aplikacji webowej.

Testy penetracyjne aplikacji webowych

Często audyt aplikacji WWW przybiera formę kontrolowanych ataków na aplikację. Działając w ten sposób audytorzy lokalizują podatności w sposób, który mógłby być wykonany przez hackerów.  Cały proces – nazywany niekiedy testem penetracyjnym aplikacji  - opisujemy bardziej szczegółowo w drugiej części artykułu.  W kolejnej części tekstu wskazujemy również bardziej ogólne i komplementarne podejścia do audytu bezpieczeństwa aplikacji webowej.

--Michał Sajdak (michal.sajdak@securitum.pl)

Więcej informacji

Przydatne informacje? Polub nas na facebooku.

Nawigacja
 
Darmowy magazyn o ITsec

zine
Subskrybuj RSS:
RSS