Jak zabezpieczyć aplikację webową

1 - Zerowa wiedza, wiele ataków

Pierwszą z metod jest przeprowadzanie dynamicznych testów penetracyjnych, w których aplikacja zainstalowana w badanym środowisku podlega zaplanowanym atakom zgodnie ze scenariuszem testowania.

Yaroslav Popov wyjaśnia: „podatności w metodzie dynamicznej wykrywa za pomocą testów penetracyjnych w środowisku podobnym do produkcyjnego. Na każdą kontrolkę aplikacji przygotowuje się tysiące różnych ataków i analizuje wyniki. Jeśli atak się powiódł, oznacza to, że podatność istnieje i wymaga usunięcia. Ze względu na ilość ataków – są to tysiące różnych prób – proces automatycznych testów przeprowadza się najczęściej nocą. Powstałe raporty są następnie przekazywane do działu deweloperskiego, a wykryte podatności – usuwane w trakcie dalszej budowy aplikacji, na przykład przy wprowadzaniu kolejnych elementów funkcjonalnych lub wersji oprogramowania. W ten sposób testuje się także podatność platformy serwerowej oraz konfiguracji środowiska”.

Zobacz również:

  • IDC CIO Summit – potencjał drzemiący w algorytmach
  • Uwierzytelnianie bez haseł – 10 rozwiązań
  • Prevalent wprowadza Alfreda, generatywnego kamerdynera AI do zarządzania ryzykiem

Proces analizy zaczyna się od crawlingu, czyli analizy aplikacji WWW, rozpoznania każdej ze stron HTML, opracowania kompletnej listy kontrolek i pobieranych informacji, które posłużą do ataku. Kolejnym krokiem jest profiling, czyli testowanie serwera, by oznaczyć jego właściwą wersję i podłączyć ataki przeznaczone dla wykrytego oprogramowania. Jest to ważny krok, gdyż można spędzić dużo czasu przy budowie dobrze napisanej i bezpiecznej aplikacji, ale jeśli będzie ona zainstalowana na źle skonfigurowanym serwerze, to prawdopodobieństwo udanego ataku rośnie. Ostatnim krokiem jest audyt, przeprowadzany wielowątkowo za pomocą skanerów, które w czasie kilku godzin badają tysiące ataków. Ze względu na złożoność działań, procesu dynamicznego testowania nie można przeprowadzić iteracyjnie ze skanem na żądanie, ale można go zintegrować z testami funkcjonalnymi, prowadzonymi regularnie w trakcie budowy aplikacji lub uruchamiać automatycznie, na przykład co wieczór.

2- Co w kodzie piszczy

Test na koniec to czyste zło

Gdyby prześledzić proces budowy aplikacji pod względem użytych i dostępnych zasobów, to najostrzejsze ograniczenia występują zawsze pod koniec projektu. W tym czasie środków w budżecie zazwyczaj już nie ma lub są one na wyczerpaniu, harmonogram realizacji zadania jest w większości już wypełniony i termin oddania gotowej aplikacji jest blisko. Wprowadzanie w tym okresie pierwszych testów podatności niesie ze sobą ryzyko biznesowe. Podobne działania należało wykonać o wiele wcześniej.

Yaroslav Popov mówi: „Proszę sobie wyobrazić ostatnie tygodnie przed oddaniem aplikacji. Budżetu już nie ma, ale test pokazał 50 krytycznych podatności znalezionych w ostatniej chwili. Czeka nas sobota i niedziela w pracy. Testy trzeba było zrobić wcześniej, skanować kod i sprawdzać aplikacje na początku, by mieć na przykład 3 miesiące na bezpieczne napisanie programu. Optymalne podejście umożliwia przeniesienie badań na wcześniejsze etapy i w ostatnim skanie przed wydaniem wyjdzie co najwyżej kilka podatności. Te luki będzie można porządnie i szybko naprawić, gdyż najgorsze podatności ze wczesnych etapów projektu już dawno zostały usunięte. Pierwsze testy przed ostatnim wydaniem to czyste zło”.

Oddzielenie założeń bezpieczeństwa od biznesowej funkcjonalności aplikacji może skutkować konfliktami, na przykład związanymi z przechowywaniem danych na urządzeniu końcowym – biznes wymaga szybkiego dostępu do informacji (dane składowane lokalnie), a z drugiej strony wymagania bezpieczeństwa wskazują na ryzyko realizacji w praktyce. Podobne decyzje należy podejmować na bardzo wczesnym etapie rozwoju aplikacji.

Zamiast testować podatności zbudowanej aplikacji, można dokładnie analizować budowę kodu źródłowego. Metoda ta zakłada skanowanie kodu w poszukiwaniu podejrzanych struktur. Wymaga dużej bazy, powoduje mnóstwo fałszywych alarmów, ale daje szansę usunięcia podatności, które obecnie nie stanowią zagrożenia, ale w innych warunkach mogłyby przyczynić się do udanego ataku.

Yaroslaw Popov wyjaśnia: „testowanie kodu aplikacji różni się od testów penetracyjnych. Tutaj patrzy się na kod i jego elementy w poszukiwaniu podejrzanych struktur. Znalezione podobieństwa wskazują na obiekty, które należy dokładniej sprawdzić. Metoda ta przynosi wiele fałszywych alarmów, ale umożliwia znalezienie luk także w tych fragmentach, które nie są obecnie używane wprost. W przyszłości jednak ktoś może taką strukturę użyć inaczej i wtedy byłoby możliwe eksploitowanie starej podatności. My taką ukrytą lukę możemy usunąć od razu na wczesnym etapie projektu”.

Aby automatycznie analizować podatności, niezbędna jest baza wielu różnych API (HP informuje o tym, że w bazie rozwiązania Static Code Analyzer znajduje się ponad 720 tys zewnętrznych API oraz frameworków), pokrywając przynajmniej 60% wszystkich obiektów, których programiści naprawdę używają. Jeśli podczas tworzenia aplikacji stosowany jest framework, dla którego istnieje baza wiedzy, to najważniejsze testy podatności można przeprowadzić automatycznie.

Cechą szczególną podobnych testów jest to, że obejmują one cały stos rozwiązania, od PHP/ASP przez SQL aż do najniższych warstw, by wychwycić i prześledzić możliwość wstrzyknięcia złośliwego kodu. Dotyczy to także aplikacji mobilnych, w których samo oprogramowanie smartfona może być napisane poprawnie, ale błędy po stronie serwera przyczynią się do włamań.

Wynikiem skanowania jest lista podatności obejmująca kontrolkę, rodzaj luki, linie kodu, w której są błędy, klasy, z których niebezpieczeństwo przychodzi oraz szczegółowe informacje. Proces wykrywania i usuwania podatności tą drogą da się przeprowadzać iteracyjnie, gdyż jest stosunkowo szybki i można go zintegrować z narzędziami budowy aplikacji (na przykład Visual Studio i Eclipse).

3- Obrońca aplikacji

Nawet jeśli aplikacja nadal posiada podatności, istnieje szansa obrony przed atakiem. W takim przypadku na serwerze można zbudować warstwę ochronną, która analizuje działanie oprogramowania. Pełni ona zadanie ostatniej linii obrony, podnosząc alarm w przypadku prawdziwego ataku.

Yaroslaw Popov mówi: „zainstalowany na poziomie maszyny wirtualnej agent obserwuje pracę aplikacji, sprawdza jakie parametry do niej przychodzą i jeśli zauważy coś, co wygląda podejrzanie, na przykład wykorzystuje potencjalnie niebezpieczne odwołania API, to podejmuje alarm. Może informować na przykład o tym, że ktoś próbuje przejąć hasło lub przeprowadzić wstrzyknięcie kodu. W ten sposób możemy szybko reagować, wprowadzając zdarzenie do systemów monitoringu. W odróżnieniu od analizy aplikacji, ta metoda działa w czasie rzeczywistym, informując o prawdziwych zdarzeniach”.


TOP 200