Aplikacja może bronić się sama

Przed niektórymi atakami nie chroni najnowocześniejsza zapora sieciowa ani inspekcja pakietów, ani nawet specjalizowane firewalle. Przedstawiamy najlepszy sposób obrony przed zagrożeniem.

Ataki na firmowe aplikacje webowe stanowią obecnie większość naruszeń bezpieczeństwa w przedsiębiorstwach, przy czym nawet najlepsze zapory i urządzenia IPS nie ochronią błędnie napisanego oprogramowania. Niektóre z podatności, takie jak SQL Injection, udaje się odfiltrować za pomocą nowoczesnych zapór sieciowych, w których można wprowadzić ograniczenia na zawartość poszczególnych pól formularzy, zanim dotrą one do serwera. Urządzenia, które to potrafią zrealizować (na przykład niektóre z zapór F5), nie ochronią aplikacji przed wszystkimi atakami, zatem to aplikacja powinna radzić sobie z niepożądanymi działaniami użytkownika. W odróżnieniu od stosunkowo prostych do zablokowania ataków SQL Injection, niektóre ataki są bardziej skomplikowane.

Pułapka opóźnia włamywacza, alarm przyspiesza interwencję

Aplikacje mają dostęp do wielu informacji nieudostępnianych użytkownikom, dlatego włamywacze próbują wykorzystać którąś z luk, by te dane pozyskać. Ponadto ograniczenia wbudowane w oprogramowanie uniemożliwiają wykonanie niektórych działań (na przykład nieautoryzowanego transferu pieniędzy), zatem po rozpoznaniu podatności cyberprzestępcy spróbują wykorzystać luki do wykonania działań, których nie udaje się przeprowadzić w normalnym trybie pracy aplikacji. Zadaniem kodu obronnego wbudowanego w aplikację jest wykrycie prób i podjęcie działań, przy czym należy myśleć raczej w kategoriach pułapek na włamywacza niż zapór chroniących dostępu. Zadaniem pułapek jest wykrycie i odrzucenie połączeń na tyle wcześnie, aby włamywacz nie zdążył wykryć podatności, lub opóźnienie ataku, by administrator zdążył zareagować na wysłane alerty i podjął inne decyzje.

Złodziej na polu minowym

Ponieważ zabezpieczenia mogą być skuteczne tylko wtedy, gdy są wbudowane w aplikację, założenia punktów poszukujących nieprawidłowości muszą być dołączone praktycznie do każdego wprowadzanego pola i kontrolować każdą akcję użytkownika. Powinny mieć jednak różną wagę - od drobnych ostrzeżeń, aż po raporty krytyczne, które oznaczają nieautoryzowane działania w aplikacji. Wykrywanie ataków powinno być jednak o wiele bardziej zaawansowane, gdyż wprowadzając dodatkowe dane, można wykryć o wiele więcej niż tylko podmianę jednego pola. Praktyka pokazuje, że dołączenie trendów systemowych, historii działania użytkownika, możliwości odpytania zewnętrznych systemów (ERP, firewall aplikacyjny) oraz połączenie z wiedzą na temat ról i uprawnień umożliwi wykrycie wielu ataków, w tym niektórych nieznanych w momencie opracowywania zabezpieczeń.

Arsenał akcji

W tradycyjnym rozumieniu korzystało się zazwyczaj z dwóch standardowych opcji odpowiedzi na atak - pracy bez zmian, ale z kompletnym logowaniem aktywności oraz przerwanie procesu (na przykład zresetowanie połączenia). Tymczasem twórcy aplikacji webowych mają cały arsenał możliwych akcji, do których należą:

działanie bez zmian;

- wzmożenie logowania, w tym ze szczegółami wewnętrznej pracy aplikacji;

- powiadomienie administratora;

- inne powiadomienie, na przykład przekazanie zgłoszenia do innego systemu;

- użycie proxy, na przykład przez przekierowanie do innego serwisu;

- zmiana statusu użytkownika, m.in. radykalne obniżenie uprawnień po wykryciu niepożądanego działania;

- powiadomienie użytkownika;

- zmiana szybkości pracy aplikacji (wprowadzenie opóźnień)

- przerwanie procesu;

- tymczasowe lub całkowite zablokowanie pewnych funkcji aplikacji

- wylogowanie użytkownika;

- wylogowanie i zablokowanie konta użytkownika;

- wyłączenie aplikacji;

- zażądanie dodatkowych informacji od użytkownika.

Wiele z tych opcji być może jest już zaimplementowane, wystarczy uzupełnić niektóre z nich i wprowadzić system detekcji, który następnie wyzwoli żądane akcje. Najbardziej prawdopodobne akcje to: zmiana poziomu logowania pracy, system powiadomień adminów, wiadomości dla użytkowników, wylogowanie, blokowanie konta i przekierowania. O wiele mniej prawdopodobne jest istnienie opcji związanych z użyciem proxy czy dodawaniem opóźnień, a także wyłączaniem poszczególnych funkcji lub nawet całej aplikacji.

Aby przyspieszyć działanie aplikacji, warto zaimplementować motor sprawdzający, który byłby wyposażony w odpowiednie narzędzia, ale pracujący poza samą aplikacją. Niekiedy można wszystkie zadania sprawdzenia przenieść na osobną maszynę, wprowadzając przy okazji sondy sprawdzające w innych elementach infrastruktury, takich jak bazy danych czy systemy serwerów front end oraz aplikacyjnych. To ważne, gdyż umożliwia wykrycie zjawisk i trendów systemowych, takich jak nagłe wylogowanie wielu użytkowników lub poważny wzrost obciążenia serwisów przy niewielkiej liczbie użytkowników zalogowanych.

Zadaniem procedur chroniących aplikację jest wykonywanie właściwych działań, przy czym jest to związane także z kontekstem pracy. Nie należy wylogowywać użytkownika w przypadku stwierdzenia prostego błędu, ale na niektóre działania system musi reagować natychmiast, aż do wyłączenia aplikacji włącznie. Typowe działanie związane z wykryciem ataku powinno się jednak wiązać z zablokowaniem dostępu, by uniemożliwić dalsze działania włamywaczowi.

Należy przy tym pamiętać, że kont uprzywilejowanych nie powinno się automatycznie blokować, ale raczej wysyłać alerty do administratorów i logować wszystkie akcje podejmowane przez takie konto, najlepiej do trwałego medium, którego nie można zdalnie zmienić.

Napastnik w potrzasku

Przy projektowaniu ochrony aplikacji warto wspomnieć o zabezpieczeniach stosowanych w praktyce przez producentów różnych rozwiązań, w tym także tych nieco odleglejszych od aplikacji webowych.

- System blokuje niekrytyczne funkcje samochodu, w przypadku wykrycia naruszenia integralności.

- Dostęp do systemów awioniki samolotu zostaje zablokowany, jeśli źródło połączenia wskazuje na sieć, do której mogli mieć dostęp pasażerowie.

- Otwarcie obudowy urządzenia usuwa klucze szyfrujące.

- Alert w przypadku rozbieżności czasu zewnętrznego w stosunku do wbudowanego zegara.

- Rejestrowanie zaników zasilania.

- Blokowanie aplikacji przez administratora w przypadku wystąpienia nadzwyczajnych okoliczności.

- Blokowanie dostępu, gdy wiadomość odpowiedzialna za automatyczne logowanie nie przechodzi testów integralności.

- Rejestrowanie działalności aplikacji.

- Wyłączenie funkcji, które są niepotrzebne do pracy aplikacji.

- Wyłączenie możliwości zablokowania konta uprzywilejowanego, ale bardzo dokładne rejestrowanie działań, z podnoszeniem natychmiastowych alertów włącznie.

- Przerywanie obsługi żądania po wykryciu zabronionych znaków (na przykład prób wykonania SQL Injection).

- Wykorzystanie gotowych narzędzi do detekcji nadużyć.

- Blokowanie dostępu po wykryciu niespójności danych w bazie.

- Rejestrowanie i blokowanie prób pobrania informacji poza aplikacją.

- Wprowadzenie dodatkowego opóźnienia po każdej nieudanej próbie zalogowania.

- Blokowanie konta po kilku nieudanych próbach dostępu.

- Blokowanie dostępu dla adresu IP na pewien czas po wykryciu prawdopodobnych prób ataku.

- Funkcja pułapki - honey pot.

- Blokowanie niektórych wyrażeń HTTP

- Rejestrowanie niespodziewanych akcji.

Gdy włamywacz szuka luki

***kropka ***Czy na pewno w tej kolejności?

Jednym z problemów, które mogą dotyczyć aplikacji webowych, jest wywoływanie poszczególnych podstron aplikacji w innej kolejności, niż przewidział producent. Problem jest na tyle poważny, że umożliwia wywołanie tych procedur, do których normalnie użytkownik nie miałby dostępu, albo wyświetlenie danych, których użytkownik nie powinien zobaczyć. Aplikacja zatem musi posiadać narzędzia kontrolujące wykonywanie poszczególnych podstron, startując od właściwego punktu wyjścia, z poprawnym uwierzytelnieniem i we właściwej kolejności. Każde odstępstwo powinno skutkować logowaniem zdarzenia, przerwaniem sesji i przekierowaniem na właściwą stronę, na przykład stronę logowania do serwisu.

***kropka***Najpierw trochę, potem więcej

Jeśli aplikacja zajmuje się dystrybucją zasobów lub transakcjami finansowymi, firma musi zwrócić uwagę na wywołanie, które może być związane z próbą wykonania nieautoryzowanej transakcji - najpierw wywoływana jest strona żądająca niewielkiej ilości zasobów (na przykład transfer.asp?amount=10), a następnie występuje takie samo wywołanie, ale z wyższą wartością (np. transfer.asp?amount=100000). Oczywiście może być to działanie uprawnionego użytkownika, ale jest to jedna ze wskazówek, które należy sprawdzić.

***KROPKA****Czy to na pewno ten profil

Niekiedy aplikacja posiada niewystarczające zabezpieczenia, umożliwiając przejrzenie informacji, do których dany użytkownik nie powinien mieć dostępu - do wykorzystania takiego błędu wystarczy wywołać stronę z inną wartością parametru (np. profil.php?id=123 zamiast prawidłowego profil.php?id=121, przypisanego danemu użytkownikowi). Oczywiście dobrze napisana aplikacja nie pozwoli na to, ale powinna również rejestrować próby wykorzystania ataków forceful browsing.

***KROPKA***Tego z aplikacji zrobić się nie da tu idzie rysunek od Marcina

Aplikacje webowe przekazują informacje, jednym ze sposobów są pola formularzy. Oprócz podawanych przez użytkownika danych występują tam informacje wymieniane między stronami za pomocą ukrytych pól. Ponieważ z poziomu interfejsu aplikacji nie ma możliwości ich zmiany, oznacza to, że każda modyfikacja oznacza próbę ataku. Zupełnie inaczej wygląda taka kontrola przy polach wprowadzanych przez użytkownika, gdzie mogą wystąpić wartości, które klasyfikuje się jako normalne, dopuszczalne po korekcie i "oczyszczeniu", nieprawidłowe - w tym przypadku można zażądać ponownego wprowadzenia - oraz wymagające odrzucenia. Gdy użytkownik ma wprowadzić numer telefonu, można się spodziewać wystąpienia niektórych znaków poza cyframi (takich jak: plus, minus, spacje, a także apostrof i tylda), co może wynikać z nawyków lub błędów przy wprowadzaniu informacji. Nie musi to oznaczać ataku, ale może wskazywać na błąd - można wtedy wyświetlić użytkownikowi stronę z informacją o oczekiwanym formacie wprowadzanego numeru, a spacje na końcu numeru usunąć. Z kolei poważniejszy błąd, taki jak wartość pola RADIO BUTTON inna niż niezerowa liczba całkowita, nieomylnie wskazuje na poszukiwanie podatności aplikacji przez włamywacza.

Jeśli w aplikacji wykorzystuje się kod JavaScript sprawdzający poprawność wprowadzonych informacji po stronie klienta, zagadnienie kontroli wygląda jednak inaczej - gdy do serwera docierają niedopuszczalne znaki, to wskazówka, że włamywacz prawdopodobnie próbuje znaleźć jakąś podatność aplikacji. Test wartości pól takich jak RADIO BUTTON lub pól ukrytych nie ma znaczenia, gdyż każde z powyżej opisywanych odstępstw nie mogło wystąpić, jeśli dane po stronie użytkownika były sprawdzone przez kod JavaScript w przeglądarce.


TOP 200