Źródło

W poprzednim poście opisałem, czym jest mechanizm AppSensor. Chciałbym teraz przedstawić dokładniej jego sposób działania i w jaki sposób pozwala na zabezpieczenie aplikacji webowej.

Korzyści

Stosowanie tego mechanizmu umożliwia nam:

• wykrywanie zagrożeń już w momencie próby ataku,
• reagowanie na niebezpieczne zdarzenia w czasie rzeczywistym,
• rozszerzenie spektrum wykrywania zagrożeń dzięki korzystaniu z kontekstu wykonywania akcji,
• zabezpieczenie systemu przed nieznanymi jeszcze podatnościami programowymi.

Elementy składowe

Sama biblioteka składa się z następujących elementów:

• punkty detekcji,
• logowanie potencjalnych zagrożeń,
• mechanizm analizy i rozpoznawania zagrożeń,
• sposoby reakcji.

Elementy te, odpowiednio połączone, pozwalają na stworzenie spójnego mechanizmu przetwarzania wszelkich niestandardowych użyć systemu. Dzięki analityce jesteśmy w stanie zgrupować te anomalie i odpowiednio, proaktywnie na nie reagować.

Właśnie element analityczny jest jednym z najważniejszych mechanizmów w całej tej układance. To dzięki niemu możemy sprawić, że ataki będą blokowane, a błędy użytkownika nie spowodują blokowania jego pracy. Sposób wykrywania ataków zależy od tego, jak wygląda interfejs użytkownika systemu oraz jak dokładne walidacje są przeprowadzane w jego zakresie. Można to zaobserwować na poniższych rysunkach:

W przypadku, gdy nie wykorzystujemy walidacji po stronie klienta, otrzymanie numeru telefonu zawierającego myślnik nie jest niezykłe. Z kolei w przypadku, gdy odrzucamy tego typu znaki po stronie klienta, otrzymanie ich na wejściu metody API zdecydowanie świadczy o nieprawidłowym użyciu takiej metody.

Dodatkowo w niektórych elementach możemy zdecydować się na skorzystanie z usług zewnętrznego dostawcy rozwiązania. Tak jest w przypadku mechanizmu logowania potencjalnych zagrożeń. Przyjrzyjmy się bliżej wszystkim elementom biblioteki.

Rodzaje punktów detekcji

Zaczynamy od punktów detekcji. Są to reguły pozwalające na rozpoznanie specyficznych dla systemu sytuacji przekroczenia zasad przekazywania danych. Projekt AppSensor definiuje typowe punkty wykrywania. Dzielą się one na następujące grupy związane z:

• zapytaniami do serwera,
• autentykacją,
• uprawnieniami,
• walidacją danych,
• zmianą trendów zachowania systemu.

Przykładami punktów detekcji mogą być:

• próba ominięcia walidacji po stronie klienta,
• próba operacji na zasobach, do których użytkownik nie ma uprawnień,
• nadużycia przy próbach logowania,
• próby przesłania niebezpiecznych znaków,
• zbyt częste używanie funkcji niedostępnych z interfejsu użytkownika.

Logowanie

Ważnym elementem składowym biblioteki jest logowanie potencjalnych niebezpieczeństw. Można tu skorzystać z zewnętrznych usługodawców lub z własnego mechanizmu. W dużej mierze zależy to od tego, jakiego mechanizmu logowania używamy już w naszej aplikacji. Ze względu na potrzebę analizowania zagrożeń ważne jest umożliwienie odczytywania tych informacji z naszej aplikacji. Logowane informacje muszą posiadać kilka istotnych z punktu widzenia analizy właściwości:

• datę i czas zdarzenia,
• punkt styku, na którym wykryto naruszenie,
• informację identyfikującą użytkownika,
• wysłane informacje,
• rodzaj wykrytego zagrożenia.

Rodzaje odpowiedzi

W odpowiedzi na rozpoznane zagrożenie możemy zastosować kilka rodzajów zachowań systemu, które mają na celu poinformowanie administratora i/lub utrudnienie dalszego ataku:

• alerty bezpieczeństwa dla administratorów,
• zwiększenie poziomu zabezpieczeń,
• wylogowanie,
• zablokowanie konta,
• akcje w warstwie infrastruktury (np. blokowanie adresów IP),
• dzielenie się danymi z innymi systemami.

Praca analityczna przy ustalaniu zagrożeń, reakcji i triggerów

Jak już wspomniałem, niezwykle istotne jest odpowiednie dopasowanie progów i zasad wykrywania, aby mechanizm ten nie był uciążliwy dla normalnych (popełniających błędy) użytkowników. Należy przeanalizować i dostosować ustawienia tak, aby pasowały do specyfiki aplikacji i firmy. Można przyjąć kilka różnych strategii działania:

• nie zabraniaj niczego użytkownikom, lecz loguj ich działania i monituj administratorów,
• informuj użytkowników o przekroczonych uprawnieniach i o monitorowaniu ich działań,
• uzależniaj poziom zabezpieczeń od kraju pochodzenia użytkownika,
• użytkownicy, którzy nie są zalogowani powinni mieć bardziej rygorystyczne ograniczenia,
• wszelkie powtarzające się podejrzane zachowania o wysokim zagrożeniu powinny wylogowywać użytkownika i/lub blokować czasowo jego konto.

Integracje z innymi systemami

Implementacja może, a niekiedy nawet powinna obejmować integracje z innymi systemami. Powinna być ona rozpatrywana już podczas fazy analizy, ponieważ obejmuje zasady reakcji na zdarzenia. Przykładowo możemy rozpatrywać łączenie się z systemami:

• w warstwie sieciowej infrastruktury (do blokowania adresów IP),
• monitoringu,
• wspomagającymi logowanie,
• statystycznej analizy ruchu sieciowego.

Możliwości adaptacji

Do gotowego systemu zabezpieczeń możemy dodać różne modyfikacje, które usprawniają cały mechanizm, np.:

• dynamiczne adaptacje progów wykrywania ataków (przy zwiększonej częstotliwości wykrywania niepoprawnych zachowań, możemy zaostrzyć kryteria akceptacji),
• dynamiczne adaptacje zachowań w zależności od sposobów ataku.

W kolejnym poście opiszę architekturę rozwiązania, które chcę zbudować.